Re: [w3ctag/design-reviews] Element Timing API (images and text) (#326)

> I think we're both OK with using this review to cover both images and text -- though based on a quick skim it seems like text is currently covered only in the explainer but not in the text. Is that correct? 

That is true - text is currently covered in the explainer but not in the spec (I imagine that's what you meant). 

> That said, it seems like it might also make sense to separate if they're going to progress at substantially different rates. It seems like the text parts probably need to be developed a good bit more before we can really review them, since it's not yet clear what they are.

I'll try to speed up the process of adding text to the spec draft, I'm just a bit bogged down in work right now :)

> * one thing I'm a little concerned about is implicit registration.  It seems like it might have substantial performance overhead since finding out whether something _should_ be implicitly registered seems like it would happen relatively late in the loading process, which would therefore require _everything_ to be tracked up until that point, which might have a bit of overhead.  Is that the case?  (I notice there's a "TODO: fix implicit registration.") in the explainer.)

Yep implicit registration is a bit of a problem right now, and we believe that the current approach (implicitly register elements that occupy a large portion of the viewport) is not good enough because many websites do not contain any element that occupies a significant portion of the viewport... The performance overhead concern is valid, but I do believe it would be very valuable to expose something here. The overhead would come from keeping track of all elements that have painted, and when the first paint occurs computing the intersectionRect and other attributes. I believe the overhead is acceptable, but can only know when we attempt to ship. An alternative would be to ship without any implicit registration - I'm hoping to avoid that.

> * does the API support vector images, or is it just raster images?  It's a little unclear.

It supports both. As long as the it's in an <img>, <image> inside <svg>, or background-image.

> * defining when images are fully loaded requires a little care for animated images.  Is the concern about the first frame of an animated raster image?

Not sure I follow this question... can you clarify?

> * there should probably be a formal-ish definition of the `elementtiming` attribute somewhere that is intended to be moved into the HTML spec eventually (and when that happens, this spec could link to it).

It is already defined in the [DOM section](https://wicg.github.io/element-timing/#sec-modifications-DOM)

> * How much discussion has there been of the naming here?  Is it better to call a bunch of different things `"element"` or to call image specific information `"image"`, etc.?

Not a lot... I think it's plausible to have an entryType for image and one for text. Filed an [issue](https://github.com/WICG/element-timing/issues/4)

> * This seems like it's tightly tied to the work that's done in the Web Performance Working Group -- to what extent has it been discussed with the other participants of that working group, and is there a plan to move it there?  (There were some points above that you said you _would_ discuss there.)

This API has also been discussed with the group and there is consensus that it is useful. We do intend to move it from incubation into the group eventually. I'll take a note to followup on the promised discussion on the 'elementtiming' attribute name, as well as maybe the entryType issue.

> * We're also curious what the level of urgency is -- are there plans to ship this soon?  Are those plans separate for images versus text?  (And if so, that also increases the urgency of bringing into the Web Performance WG and getting it discussed effectively there...)

We'd like to ship in September. I'd like to point out: this has been presented to the group. I can share meeting notes with you if that would be helpful, but what other type of discussion are you envisioning? In any case, the spec is not ready, so I'll send a ping to members of the group from other browser vendors to provide feedback if they wish, once the spec is in better shape.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/326#issuecomment-494947186