See also: IRC log
<scribe> Scribe: chaals
<johanneswilm> https://lists.w3.org/Archives/Public/public-editing-tf/2017Sep/0000.html
JW: Chrome says
queryCommand(ṕaste´) comes out true even when it will not
work
... should it be true if paste is supported, or if it is
supported *here*
GL: Should be true if it is supported
JW: Chrome only supports it for extensions, never for regular scripts - for security
GL: Trying to think of a use
case.
... trying to see if it is generally supported. If Chrome
returns true outside an extension... ??
<johanneswilm> https://bugs.chromium.org/p/chromium/issues/detail?id=757140#c4
GL: What is the problem?
JW: Bug report. Someone tried to
make an editor and use it.
... and Chrome answering true makes it hard to key off
reality.
... Yosin says the spec is not clear...
... Ryosuke thinks it is a bug in Chrome.
CMN: Iḿ with Grisha that it is OK if it fails to work in a given instance but returns true, but if for example you are in a different security environment and that means it will always or never work, it should return accordingly.
GL: querySupported should return true if tehre is an API, assuming that you are in an environment where it will work - i.e different security levels get different answers.
JW: Should we say that if it will always fail, then it must be false in that environment?
GL: Web developers want to know if it works now, but if we say that it returns false, then people can assume that false will be false all the time.
JW: If tyhe tool finds paste is
not supported, then it needs to do a bunch of work to trell the
user how to make a paste. That is at least one common use
case.
... what people will do is learn Chrome does not support paste
and assume that means never.
CMN: This is the complexity of feature testing. In this case, telling devs on the open web that something will not work is OK, because the only developers that can use it are those working more closely, with extensions. On the open web it will not work anyway.
GL: What about trusted domains? It is similar...
JW: You cannot change the domain when you are on a page, so you are wherever you started.
GL: Yep. That works.
RESOLUTION: Spec should say that supported should be false if you are in an environment where you are always going to fail.
JW: In UI events it says when the DOM is going to change, in Input Events it is more detailed. SHould it be in both specs, how do we fit it in?
CMN: I think it should be into the UI events spec - that is where people look when they are trying to undertstand the whole ordering...
JW: Input event spec describes
the whole event, UI events describes when the thing is
triggered. They do not want to bloat the UI Event spec but what
it says is not quite right.
... SHould be the same text in both.
GL: It fires on combination of DOM going to change as the result of a user action (the second bit is missing)
JW: So can we ask UI events to adopt our text on that?
GL: Yep, that makes sense for consistency. Open an issue on UI events?
LJW: Seems like the best approach.
JW: Did, but no response
LJW: I can chase that for you
JW: We were asked by TAG to
change the definition of colors for text and backgrounds. I
think only Safari does it.
... we have simple RGB colours and they want to add
transparency.
... I would just say Yes...
CMN: WfM
GL: No strong opinion
JW: Full justification - we have
left-, right- and center-justified, and they want
full-justification.
... Why do we say left/right instead of left-align? Because
some people say that...
... simplest change is to add full-justification
LJW: If we move to left-align is that a hassle?
JW: Probably - this is out in the wild already, so we would have to support them still.
LW: Devs would understand left-align better...
CMN: Yes. If we make the change, how long do we have to support dual tokens? forever?
JW: We have agreement to add
full-justification, but adding left-align would be a new
step...
... do we want to take those steps?
CMN: I can live with only adding full-justification and not changing the others...
RESOLUTION: Add full-justification.
JW: Had some pushback. CKEditor
liked it, @@ said they would probably use it.
... some dictionary-like website did not see the point. They do
not want smileys, stickers, etc.
GL: This can be any rich content,
not just stickers but music, video, etc.
... depends on how we will implement - how to handle e.g. paste
of an image going through a data blob to get the right format,
etc.
... or is it a straight insertion and the browser will create
the element it wants and reference the image.
JW: My communication was stickers
are something apart from normal paste which you could already
do, but if this included some metadata to let you do more that
might be interesting.
... you have to think about it because if you have lots of
types of things you want to support you will find people not
doingit, but if there are say 5, then people will.
... maybe you should continue to work on it.
GL: This is not urgent, just
trying to figure out a path for this and if it should go into
beforeInput
... and from there declare the metadata and work through the
use cases.
JW: Seems like beforeInpout is a proper spot for it
LW: This sounbds like a substantial feature - is it worth letting it come in a later version?
GL: Absolutely - at this stage it is pretty much investigation.
CMN: Feels like something between paste and beforeInput...
JW: Editors want to get the information about what they are actually receiving...
GL: We could use a clone of the
clipboard object, with a separate entity so as not to override
the clipboard
... and reuse the object without going through the
clipboard.
JW: Similar to DnD?
GL: Yeah, probably.
... or we can do different things. But that has infrastructure
already so sort of makes sense. But as a Wb Dev it will be
treated something like a paste object.
JW: So if web deve listens to
beforeInput you get drag, or paste, or enriched input with
metadata.
... and that is where you find the extra metadata.
GL: So, if I want to play with the spec and make changes, should I just fork it and make PRs or just make proposals on GH Issues?
JW: I would be in favour of you making a fork and Pull Requests...
GL: question on shipping. Feature should be operational, not just behind a flag, to count for interoperability.
CMN: Depends. If all implementations are behind flags there is more attention to why. Basically it depends how strong the implementation interop story is...
JW: There are some other initial points in the email for the TPAC agenda - we will keep building it as we go.
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/Getting people to meetings/@@/ Succeeded: s/e.e/e/ Succeeded: s/flase/false/ Succeeded: s/sai/said/ Present: Chaals Grisha Johannes Léonie tink Found Scribe: chaals Inferring ScribeNick: chaals Got date from IRC log name: 05 Sep 2017 Guessing minutes URL: http://www.w3.org/2017/09/05-editing-minutes.html People with action items:[End of scribe.perl diagnostic output]