Re: Components F2F
On Thu, Jul 2, 2015 at 8:56 AM, Ryosuke Niwa rn...@apple.com wrote: Is Google hosting this meeting as well? Alternatively, would other browser vendors (e.g. Mozilla) willing to host it this time? If we decide quickly it seems I can reserve a room at Mozilla for 18 people in SF, maybe 22 in MTV. Not sure that's big enough judging from last meeting, but I don't have the details. I'm supposed to write up a document that summaries what we've agreed thus far. I've been busy with other stuff lately but will try to post it before the meeting. Excellent! -- https://annevankesteren.nl/
Re: Components F2F
On Jun 30, 2015, at 2:55 AM, Anne van Kesteren ann...@annevk.nl wrote: Can someone update https://www.w3.org/wiki/Webapps/WebComponentsJuly2015Meeting with a bit more information? I hear it might be in Mountain View? Is Google hosting this meeting as well? Alternatively, would other browser vendors (e.g. Mozilla) willing to host it this time? Unfortunately, it's going to be really hard to reserve a big enough room at Apple :( I'm hoping that'll change once we move to the new spaceship but we'll see... Will we have sufficient time to cover both Custom Elements and Shadow DOM? And could the drafts maybe be updated to cover what has been agreed to so far? E.g. it seems we have agreement on slots and I think that was the last major thing from Shadow DOM that needed a solution. Would be great if we could review a complete document. I'm supposed to write up a document that summaries what we've agreed thus far. I've been busy with other stuff lately but will try to post it before the meeting. - R. Niwa
Re: Custom Elements: is=
On Jun 13, 2015, at 4:49 PM, Léonie Watson lwat...@paciellogroup.com wrote: From: Bruce Lawson [mailto:bru...@opera.com] Sent: 13 June 2015 16:34 On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button extends=button attributesPush/my-button because browsers that don't know about web components wouldn't pay any attention to my-button, and render Push as plain text. Of course! I should have thought of that. That's not entirely true. If the implementation of my-button, let us call it MyButtonElement had the prototype that extends HTMLButtonElement, then the browser can set role=button just fine. On Jun 13, 2015, at 5:41 PM, Patrick H. Lauke re...@splintered.co.uk wrote: On 13/06/2015 16:33, Bruce Lawson wrote: On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com wrote: why not use the extends= syntax you mentioned? my-button extends=button attributesPush/my-button because browsers that don't know about web components wouldn't pay any attention to my-button, and render Push as plain text. Browsers that don't know about web components will fall back to button with button this-is-made-much-more-marvellous-by=my-button (or whatever) However, this fallback will only really be useful for very simple cases, where web components have been used to jazz up what essentially is still the element that was extended. And, I would posit, any scripting that was done to act on the all-singing, all-dancing new web component button (if it does anything more than a regular button) would not work for the fallback. Unless it's really just using web components for fancy styling (for instance having a material design button that essentially still works just like a button) - in which case, it makes more sense to work on stylability of standard elements. Precisely! I've been saying that for the last two years. It's so nice refreshing to hear someone making the same argument :) And we (Apple) would love to solve the stylability issue of form elements. - R. Niwa
Custom Elements: createdCallback cloning
In the interest of moving forward I tried to more seriously consider Dmitry's approach. Based on es-discussion discussion https://esdiscuss.org/topic/will-any-new-features-be-tied-to-constructors it seems likely new JavaScript features (such as private state) will be tied to object creation. This makes the prototype-swizzling design even less appealing, in my opinion. Meanwhile, I have not made much progress on the cloning question. As Domenic pointed out, that would also either require prototype-swizzling or invoking the constructor, there's not really a third way. I guess for that to work cloneNode() and various editing operations would have to become resilient against JavaScript executing in the middle of them, something that has caused (is causing?) us a ton of headaches with mutation events. (Or the alternative, have some kind of mode switch for the DOM which is similarly a large undertaking.) Not sure what to do now :-/ -- https://annevankesteren.nl/
Re: Better focus support for Shadow DOM
Hi, Changes for Blink have landed and now you can play this by enabling experimental web platform features in chrome://flags. Now I am proposing this as a patch to shadow DOM, at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/ShadowRoot-delegatesFocus-Proposal.md Feel free to comment here, or at github issue tracker. (The full version of the doc also moved to markdown format, at https://github.com/TakayoshiKochi/tabindex-focus-navigation-explainer/blob/master/TabindexFocusNavigationExplainer.md ) On Wed, Jun 3, 2015 at 4:47 PM, Takayoshi Kochi (河内 隆仁) ko...@google.com wrote: Hi, (cross-posting mostly the same content to blink-...@chromium.org, sorry for duplication if you encounter this twice) With much feedback from many people, I've updated the design doc. https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Thanks all who have shared thoughts and experience with me. The biggest change is that tabStop property on Element moved to ShadowRoot, as delegatesFocus. After implementing the spec on Blink, I noticed that even tabStop property is on every Element, it has effect only on shadow hosts, which is very confusing. So delegatesFocus should make more clear sense on shadow hosts. With the new spec, delegatesFocus can be specified via ShadowRootInit dictionary, which is a parameter to createShadowRoot(). I'll start making changes in Blink immediately. For reference, I copied a snapshot of old doc (Mar. 19): https://docs.google.com/document/d/1wFXrPYmoqb8-b-rfZdmcVfZt09NaTFyOLvGztdlIPxE/edit# Any comment is welcome. On Thu, Jan 22, 2015 at 6:38 AM, Domenic Denicola d...@domenic.me wrote: Thanks Takoyoshi! This new version looks great to me. It would allow people to create custom elements with the same focus capabilities as native elements, including both the simple cases (like custom-a) and the more complicated ones with a shadow DOM (like custom-input type=date). Very exciting stuff! I hope others are as enthused as I am :) *From:* Takayoshi Kochi (河内 隆仁) [mailto:ko...@google.com] *Sent:* Wednesday, January 21, 2015 02:41 *To:* public-webapps *Subject:* Re: Better focus support for Shadow DOM Hi, After conversation with Domenic Denicola, I changed the title and the whole story of solving this issue, though the result is not quite different. Instead of adding delegatesFocus property, we added isTabStop() to expose tab focusable flag explained in HTML5 spec. https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments/suggestions welcome. On Wed, Jan 14, 2015 at 2:27 PM, Takayoshi Kochi (河内 隆仁) ko...@google.com wrote: Hi, For shadow DOMs which has multiple focusable fields under the host, the current behavior of tab navigation order gets somewhat weird when you want to specify tabindex explicitly. This is the doc to introduce a new attribute delegatesFocus to resolve the issue. https://docs.google.com/document/d/1k93Ez6yNSyWQDtGjdJJqTBPmljk9l2WS3JTe5OHHB50/edit?usp=sharing Any comments are welcome! -- Takayoshi Kochi -- Takayoshi Kochi -- Takayoshi Kochi -- Takayoshi Kochi
Re: Components F2F
Google had offered to host the meeting, and I believe they are on it. Obviously, offers to share the hosting effort are welcome in general. I haven't checked but agree that based on last time 22 might be squeezing it. cheers 02.07.2015, 09:11, Anne van Kesteren ann...@annevk.nl: On Thu, Jul 2, 2015 at 8:56 AM, Ryosuke Niwa rn...@apple.com wrote: Is Google hosting this meeting as well? Alternatively, would other browser vendors (e.g. Mozilla) willing to host it this time? If we decide quickly it seems I can reserve a room at Mozilla for 18 people in SF, maybe 22 in MTV. Not sure that's big enough judging from last meeting, but I don't have the details. I'm supposed to write up a document that summaries what we've agreed thus far. I've been busy with other stuff lately but will try to post it before the meeting. Excellent! -- https://annevankesteren.nl/ -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
RE: [ime-api] [blink-dev] Removing IME API code from Blink
Arrg. It's far-less used than I thought. It turns out that it _was_ used in production last year, but then it was removed from production when a UI change interfered and the bug to fix it is still open :( So, my guess is that as of today, we have infinitesimal-small usage of this API in IE. -Original Message- From: Travis Leithead Sent: Thursday, June 18, 2015 11:49 AM To: 'Arthur Barstow'; Ryosuke Niwa Cc: public-webapps Subject: RE: [ime-api] [blink-dev] Removing IME API code from Blink I've posted the notice on the editor's draft as suggested below. If there is help to continue to advance the direction of this spec, I'd love to see it continue to evolve. Note, that our Chinese Bing home page (http://www.bing.com/?mkt=zh-CN) employs the use of a version of this API (prefixed, in IE11 Edge), but the API only lights up when you use built-in Microsoft IMEs (not 3rd party IMEs at the moment :( ). -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: Thursday, June 11, 2015 3:42 AM To: Travis Leithead; Ryosuke Niwa Cc: public-webapps Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink On 5/28/15 2:04 PM, Travis Leithead wrote: That sounds good to me (working the UI challenges for IME together with grammar/spell checking). Is this a direction the current IME spec could take--possibly with a big refactor to consider dropping the ClientRect exposure--or would it be better to publish as Note the current approach and start a new spec? Perhaps it doesn't really matter as the above is a process question, and what is really needed is someone to start suggesting some concrete proposals here--I've been pretty much ignoring this spec for the past year, and I don't see that changing in the near future. It's still something I'd like to see moved forward, I just don't believe I have the time to move it substantially forward at the present moment :) Given this, it seems like the SoTD section should include some type of large-ish warning/note that include text along the lines of `no one is actively working on this spec nor its implementation` + `help wanted`. Also, if the spec's [Issues] and [Bugs] haven't properly captured the ClientRect exposure issue, perhaps one should be created (and/or the spec updated to reflect this). On the other hand, if you propose to formally stop work on the spec as it is now, then it would be appropriate to have a CfC to publish a WG Note (and if/when there is a firm commitment to do some type of followup work, a new spec can be created). WDYT? -Thanks, ArtB [Issues] https://github.com/w3c/ime-api/issues [Bugs] https://www.w3.org/Bugs/Public/buglist.cgi?component=IME%20APIlist_id=57282product=WebAppsWGresolution=--- -Original Message- From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Wednesday, May 27, 2015 7:00 PM To: Travis Leithead Cc: Arthur Barstow; public-webapps Subject: Re: [ime-api] [blink-dev] Removing IME API code from Blink On May 27, 2015, at 11:46 AM, Travis Leithead travis.leith...@microsoft.com wrote: I believed the use-cases for avoiding UI clashes between site-driven auto-complete lists and IME auto-complete boxes is still a valid use case, and I think the spec is still valid to try to push to recommendation. However, I'd also like to follow up on usage of the ms- prefixed API so that I can get an idea of what its real usage is. I agree avoiding UI clashes between auto-completions of IME and web page is a great use case but I'm not convinced that exposing ClientRect for IME is the right API as many Web developers aren't even aware of UI challenges IME imposes. For example, a similar UI challenge emerges when dealing with auto-corrections in grammar/spell checking features as well. It would be ideal if IME and spell/grammar corrections are handled in a similar manner so that Web apps supporting either feature will just work with both features. - R. Niwa
Re: Async Image - ImageData conversion
I'm not sure having a hub is worth the implementation pain.
It looks like there are three pretty different things here:
ImageBitmap - Immutable images for drawing on canvas. Typically
premultiplied data located on the GPU
ImageData - Mutable script accessible array of data. Unpremultiplied
data located in main memory
ImageElement/Blob - A pointer to some compressed image data.
Unpremultiplied - premultiplied is a lossy conversion step which can
cause additional implementor/user pain.
i.e. if you have an ImageData and you want to make it into a blob,
it's not clear if the browser will
do unpremul - premul - unpremul encoded images or unpremul -
unpremul encoded.
It's seems like the easiest thing for users and implementors is just
to add the necessary functions in all
of the important places:
The important ones of these are:
Blob - ImageData
HTMLImageElement - ImageData
ImageData - Blob
There are a bunch of conversions that aren't covered directly by these but I'm
not sure it makes us much sense to short circut them beyond what functionality
is currently exposed. e.g.
Going HTMLVideoElement - ImageBitmap - Blob
isn't really much worse than doing:
HTMLVideoElement - CanvasRenderContext2D - Blob
-Jeff
On Thu, Jul 2, 2015 at 3:05 PM, Justin Novosad ju...@google.com wrote:
Making ImageData the hub would imply more copies in memory in many cases.
Because ImageData is mutable (not to mention the alpha multiplication issues
which are also a factor), it cannot share its image buffer with the source
it was created from, unlike ImageBitmap. Immutability is a significant
advantage of ImageBitmap, which allows for zero-copy code paths in many
cases, which helps with both performance and memory consumption.
On Tue, Jun 30, 2015 at 4:17 PM, Ashley Gullen ash...@scirra.com wrote:
If it's difficult to make ImageBitmap both an efficient drawing source and
a conversion intermediary, then we could add conversion functions to each
object that can be converted, e.g.:
HTMLImageElement.toBlob()
HTMLImageElement.toImageData()
Blob.toImageData()
ImageData.toBlob()
This seems inconsistent. For example to convert a Blob to an Image, you
should create a URL and set an Image's src to it; to convert a Blob to an
ImageBitmap, you should use createImageBitmap(blob); and then under this
proposal there's a third approach to convert a Blob to an ImageData, using
Blob.toImageData(). It also has a larger surface area, requiring changes to
several interfaces.
So perhaps it would be better to make ImageData the hub of conversion,
more like the first proposal I made. If ImageBitmap is a GPU-hosted
premultiplied resource, then ImageData is an expressly not-on-GPU
not-premultiplied alternative. That would mean adding something like this to
ImageData:
typedef (HTMLImageElement or Blob or ImageBitmap) ImageDataSource;
partial interface ImageData {
static PromiseImageData create(ImageDataSource source)
PromiseBlob toBlob()
}
ImageData can also be converted to HTMLImageElement via toBlob,
ImageBitmap via createImageBitmap, or a canvas via putImageData (which is
still synchronous, but no longer needs to be done purely for conversion
reasons, so probably means you really want it to appear in the canvas and
therefore should remain synchronous).
This covers all the conversion use cases I can think of without
complicating ImageBitmap's without undue latency requirement. There's no
more transferring going on either, which I think is now unnecessary since
you can get from HTMLImageElement to ImageData with one call. I think it's
more future-proof too since future types can be added to ImageDataSource
allowing new types to be converted without a new method being added.
Does this approach sound better?
Ashley
On 26 June 2015 at 16:37, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/26/15 4:07 AM, Ashley Gullen wrote:
I don't think we should extend HTMLImageElement because it is not
available in workers. Adding the conversion methods to ImageBitmap
allows workers to perform conversions using Blob (compressed image data)
in the place of HTMLImageElement.
Maybe I wasn't clear. I was suggesting that we have the methods on both
HTMLImageElement and ImageBitmap (and possibly on any other things we feel
should have the methods directly).
I like the suggestion that ImageBitmap be the hub of image conversion,
I agree that it sounds appealing, but it means ImageBitmap now has to
serve two masters: it has to be something that you can paint from quickly
(premultiplied, probably lives on the GPU) _and_ it needs to be something
you can transferToImageData efficiently (better to not live on the GPU for
this).
Maybe that's OK; it's just a bit of a warning flag from my point of view
when a single object is meant to do multiple quite different things; it
makes it harder to have it be good at all of them...
-Boris
Re: [shadow-dom] ::before/after on shadow hosts
Sorry for coming late, but - crbug.com/393490 Before and After pseudo elements don't work in ShadowRoots (with :host styles) - crbug.com/393509 :host()::before or :host()::after should work have the relevant discussion about the current implementation in Blink (#2). On Thu, Jul 2, 2015 at 1:16 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: All right, sounds pretty unanimous that #2 (current behavior) is what we should go with. I'll clarify the Scoping spec. Thanks! ~TJ -- Takayoshi Kochi
Re: CR: Web Storage (Second Edition)
http://www.w3.org/TR/2015/CR-webstorage-20150609/
Particpate: [sic]
the event must have its key attribute initialised to the name of the key in
question,
`initialized` [About 11,800,000 results] should be spelled as such for
w3c specs (w3c is en-us) instead of
`initialised` [About 553,000 results]
but require the user to authorise access to local storage areas.
`authorize` [About 80,100,000 results] should be spelled as such for
w3c specs (w3c is en-us) instead of `authorise` [About 6,960,000
results]
Alternatives that do not require a user-agent-wide per-origin script lock are
eagerly sought after.
sought-after [1]
Each site has its own separate storage area.
area = areas | storage = local storage
(must, should, may, etc)
etc.
If the given key does exist in the list, and its value is not equal to value,
then it must have its value updated to value. If its previous value is equal
to value, then the method must do nothing.
if the methods did not throw an exception or do nothing as defined above
it'd be nice if the above sections underlined/otherwise styled `do nothing`.
User agents should always avoid deleting data while a script that could
access that data is running.
consider a script which does:
var global_state = window.localStorage.getItem(value);
function uses_global_state() { if (global_state == 5) { }}
window.setTimeout(uses_global_state, 200);
between the script's initial execution, and the firing of the timeout,
is the script considered to be `running`?
[1] http://dictionary.reference.com/browse/sought-after
Re: Async Image - ImageData conversion
Making ImageData the hub would imply more copies in memory in many cases.
Because ImageData is mutable (not to mention the alpha multiplication
issues which are also a factor), it cannot share its image buffer with the
source it was created from, unlike ImageBitmap. Immutability is a
significant advantage of ImageBitmap, which allows for zero-copy code paths
in many cases, which helps with both performance and memory consumption.
On Tue, Jun 30, 2015 at 4:17 PM, Ashley Gullen ash...@scirra.com wrote:
If it's difficult to make ImageBitmap both an efficient drawing source and
a conversion intermediary, then we could add conversion functions to each
object that can be converted, e.g.:
HTMLImageElement.toBlob()
HTMLImageElement.toImageData()
Blob.toImageData()
ImageData.toBlob()
This seems inconsistent. For example to convert a Blob to an Image, you
should create a URL and set an Image's src to it; to convert a Blob to an
ImageBitmap, you should use createImageBitmap(blob); and then under this
proposal there's a third approach to convert a Blob to an ImageData, using
Blob.toImageData(). It also has a larger surface area, requiring changes to
several interfaces.
So perhaps it would be better to make ImageData the hub of conversion,
more like the first proposal I made. If ImageBitmap is a GPU-hosted
premultiplied resource, then ImageData is an expressly not-on-GPU
not-premultiplied alternative. That would mean adding something like this
to ImageData:
typedef (HTMLImageElement or Blob or ImageBitmap) ImageDataSource;
partial interface ImageData {
static PromiseImageData create(ImageDataSource source)
PromiseBlob toBlob()
}
ImageData can also be converted to HTMLImageElement via toBlob,
ImageBitmap via createImageBitmap, or a canvas via putImageData (which is
still synchronous, but no longer needs to be done purely for conversion
reasons, so probably means you really want it to appear in the canvas and
therefore should remain synchronous).
This covers all the conversion use cases I can think of without
complicating ImageBitmap's without undue latency requirement. There's no
more transferring going on either, which I think is now unnecessary since
you can get from HTMLImageElement to ImageData with one call. I think it's
more future-proof too since future types can be added to ImageDataSource
allowing new types to be converted without a new method being added.
Does this approach sound better?
Ashley
On 26 June 2015 at 16:37, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/26/15 4:07 AM, Ashley Gullen wrote:
I don't think we should extend HTMLImageElement because it is not
available in workers. Adding the conversion methods to ImageBitmap
allows workers to perform conversions using Blob (compressed image data)
in the place of HTMLImageElement.
Maybe I wasn't clear. I was suggesting that we have the methods on both
HTMLImageElement and ImageBitmap (and possibly on any other things we feel
should have the methods directly).
I like the suggestion that ImageBitmap be the hub of image conversion,
I agree that it sounds appealing, but it means ImageBitmap now has to
serve two masters: it has to be something that you can paint from quickly
(premultiplied, probably lives on the GPU) _and_ it needs to be something
you can transferToImageData efficiently (better to not live on the GPU for
this).
Maybe that's OK; it's just a bit of a warning flag from my point of view
when a single object is meant to do multiple quite different things; it
makes it harder to have it be good at all of them...
-Boris
