Meeting minutes
Input events (PR 122)
github: https://
johanneswilm: Was going to merge this PR, but wanted to get additional confirmation from the group...
… wanted to get implementer confirmation that we aren't removing something important.
BoCupp: yes, I will respond
johanneswilm: seems the commenter is actually using these events in their editor, and can't see an alternative.
BoCupp: assuming, this meant how to get the range for what is going to be converted. The IME decides what those extents are. The first CompositionUpdate is no different from any other, and the range is the same each time...
… also masayuki suggested that you could use selection... but this is not implemented in chromium.
… by the time the compositionstart fired, firefox will expand the range to encompass the part that will be reconverted.
… I think this is unique to firefox. I'm OK with this being sanctioned as good behavior--however, I think it might be unnecessary because insertCompositionText gives you the same thing.
… I've been pushing that insertCompositionText be the same (dependable) each time. Hoping that makes it easier vs using the other events.
… I will post on the issue regarding this.
… Might spin off a separate issue.
johanneswilm: user claims that there may be a way around it. Bo, please continue discussing to get clarity. If your proposed solution...
… to determine the range to be reconverted, one can use getTargetRanges of the first insertCompositionText event...
… be filed as a new issue.
Sanitize clipboard issue
github: https://
BoCupp: what do we need from the WG on this issue?
snianu: We will be taking this discussion to the chromium security group (for chromium only).
BoCupp: pastes are unpredictable...
… can't tell if a 3rd party messes with the clipboard.
… the question is whether there's some expected behavior from App to browser...
whsieh: We were thinking about adding things to the spec to fix compatibility in the short term. But, if we keep this the same (left to user agent discretion), we are OK with that.
BoCupp: We don't think that keeping the spec as-is will be harmful, etc. Propose we can close the issue now.
ACTION: BoCupp to close this issue; keep whsieh appraised of the security review (as FYI).
virtual-keyboard concern for screen reader users
github: https://
BoCupp: Will requires a bit of research...
… we've tried to reproduce the problem
… in theory you change the visual viewport and then auto scroll-into-view (default for some chromium platforms)... then the screen reader is unaware of the movement?
ACTION: BoCupp to investigate this report and report back with findings
a?
editcontext issues
BoCupp: alexk and I reviewed many of annevk's issues...
alexk: I don't think there are any conflicts, just need more clarifications in the spec.
johanneswilm: if there are any concerns, please feel free to bring them up here.
BoCupp: also we got feedback from masayuki around the implementation...
… whsieh do you have any thoughts on when you might dig in?
… for example, masayuki was saying firefox has an async architecture which leads to them needing to cache things...
… this potentially impacts the shape of the API
… was very useful.
whsieh: yes, and for the record, our IME is all out of proc.
… we have a similar caching mechanism.
… can't comment on exactly when we might get to this.
alexk: I sent a note to webkit dev, might want to take a look?
whsieh: absolutely.
johanneswilm: what is chromium's scheduling plans?
alexk: can't comment on exactly when we might ship (but we hope sooner than later)
whsieh: I think Adobe also expressed interest.
a?
pr for pickling
Anupam: now that the other issue is unblocked, can we proceed?
BoCupp: somewhere we need to document the options (including the keyword 'unsanitized'
Anupam: a member of the clipboard options... takes a sequence.
BoCupp: what should we do about this... we previously said we don't have to document whether to sanitize or now..
… but if you're not going to sanitize, we'd like to see the flag specified...
… where should we write that in?
whsieh: this is for clarity with legacy apps that won't be expecting changes here.
… there are ways to signal hints that don't require adding things to the spec.
… e.g., <meta> tag, with someting "unsanitized clipboard"
… that's just one idea to insure compat without injecting this concept into the HTML spec.
BoCupp: As opposed to adding an unsanitized option to the JS API?
whsieh: yep.
BoCupp: That's a pretty global specifier for ever read... wondering out lout about that scenario...
… should it be per-call?
… hmm. would it be better or worse?
BoCupp: I think there is value to provide the 'insert-ready' content (as is done today).
johanneswilm: the content still needs to be sanitized?
BoCupp: you mean understanding the model? Rather than scrubbing an onclick handler?
johanneswilm: right. In userland, need to make sure it works with your model.
BoCupp: There is a sanitizer API (proposed somewhere), if it were baked into the UA, then this is relief to the author, since it'll be built-in (and kept up to date by the UA).
… benefit of relying on the browser rather than a JS framework.
… we want to work with JS-implmenters too
… (some things in the sanitizer rules are more gray--style properties for example)
… we'd love an option here. Would love to have it in the spec (with a 'MAY' language).
… had heard resistance to that in the past.
whsieh: meta tag proposal was hopefully going to address those past concerns and provide a solution?
… one more idea--what if the value of the meta-tag is changed during paste?
BoCupp: ergonomics don't seem great. The locality of influencing the API with arguments seems better to me.
… at a minimum we might not include something in the spec, but could ship something to handle this?
… still better to document?
whsieh: if the author sends extra argument to a JS API it's not harmful...
Travis: but does prevent future extensibility.
Anumpam: there is presentationStyle attribute already...
… on the options dialog.
whsieh: would prefer a global switch as a back-up plan?
(discussion around utility of specifying this)
(discussion around potentially prefixing something)
Travis: how about 'legacyUnsanitizedHTML' ?
… ;-)
BoCupp: maybe putting a non-normative note in the spec that raises awareness of this thing.
Travis: would prefer a minimal note only w/ link out to somewhere with more details (MDN?)
(discussion on how a sanitizer API might fit into the use-case)
BoCupp: now seems to be a question of where and how to document this.
whsieh: minor naming suggestion to underscore the hint-nature of the flag...
… should have some preference or hint baked into the name
travis: 'unsanitized_hint_do_not_use'
… naming is hard.
Anupam: pointing out some of the potential issues with multiple clipboard items... (there are other platform-specific quirks)
BoCupp: We will put in a note... with link to somewhere (MDN?) and will fill-in the details there.
RRSAgent: make the minutes
RRSAgent: make logs public
RRSAgent: make the minutes
RRSAgent: make logs public
RRSAgent: please publish the minutes