Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include algorithms and concepts from Element Timing and LCP #100

Merged
merged 9 commits into from
Jan 10, 2024
Merged

Conversation

clelland
Copy link
Contributor

@clelland clelland commented Nov 16, 2023

This is part of a larger refactor of all three specs, making this spec (Paint Timing) the foundational spec for all paint-timing-related standards.


Preview | Diff

This is part of a larger refactor of all three specs, making this spec (Paint
Timing) the foundational spec for all paint-timing-related standards.
@clelland clelland marked this pull request as draft November 16, 2023 18:52
@clelland clelland marked this pull request as ready for review November 21, 2023 18:40
clelland added a commit to w3c/largest-contentful-paint that referenced this pull request Nov 21, 2023
Copy link
Contributor

@yoavweiss yoavweiss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this!!

index.bs Outdated
Recording paint timing {#sec-recording-paint-timing}
--------------------------------------------------------

<h4 id="sec-modifications-dom">Modifications to the DOM specification</h4>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want this to monkey-patch DOM or other specifications.

I think it's fine to define the "associated image request" concept here, and then populate it in the various image loading algorithms in HTML, given the fact that this supports LCP, which has cross-implementer support. It's also fine to do this in multiple stages (land the vague language now, while PRing hooks into the processing model)

index.bs Outdated

When the user agent is executing the <a>painting order</a>, it must populate the <a>set of owned text nodes</a> of the painted {{Element|Elements}} so that the following is true:

<div algorithm="text aggregation">
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be defined as an algorithm that would then be called from the processing model that populates the set of owned text nodes?

Copy link
Contributor

@noamr noamr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this!
I feel that a lot of the wording here is vague... is it copied from the existing LCP/element-timing spec? I'd feel more comfortable with using this opportunity to make the spec language more rigorous.

index.bs Outdated

<h4 id="sec-modifications-CSS">Modifications to the CSS specification</h4>

When the user agent is executing the <a>painting order</a>, it must populate the <a>set of owned text nodes</a> of the painted {{Element|Elements}} so that the following is true:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit strange. How is the painting order (which is about stacking context) related here? Sounds like something that belongs in an implementation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question! (And yes, it was moved over from element timing, where it was added pretty early, and maybe could have had more review at the time).

"Executing the painting order" isn't really something that happens: things are painted, and the painting order defines the order that they are painted in, but nothing in that section appears to be an algorithm that gets run when painting actually happens.

index.bs Outdated Show resolved Hide resolved
index.bs Outdated
When the processing model for the {{Element}} <em>element</em>'s style requires a new image resource (to be displayed as background image), the <a>image request</a> created by the new resource is appended to <em>element</em>'s <a>associated background image requests</a>.
Whenever an <a>image request</a> in an {{Element}} <em>element</em>'s <a>associated background image requests</a> becomes <a>completely available</a>, run the algorithm to <a>process an image that finished loading</a> with <em>element</em> and <a>image request</a> as inputs.

NOTE: we assume that there is one <a>image request</a> for each {{Element}} that a <a>background-image</a> property affects and for each URL that the <a>background-image</a> property specifies.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be reworded as a clear example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reworded. Hopefully clear.

index.bs Outdated Show resolved Hide resolved
index.bs Outdated
1. If |element|'s <a>set of owned text nodes</a> is empty, continue.
1. <a for="set">Append</a> |element| to |doc|'s <a>set of elements with rendered text</a>.
1. [=set/Append=] |element| to |paintedTextNodes|.
1. Run [=the paint timing steps=] given |document|, |paintTimestamp|,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't usually have this pluggable pattern in specs... it's better to call the specific ones

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a better spec pattern that can be used to provide a hook here for related specs?
LCP and ET both append steps to the paint timing steps in the current model, for instance. I'd like to have a way to make this extensible, without having to reference those specs here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Referencing them here would be the pattern. That's how we do that in the HTML spec for instance, it references many other specs that might be at a "higher level".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea I would simply call:

  • Report paint timing given ...
  • Report element timing given...

index.bs Outdated Show resolved Hide resolved
index.bs Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
@clelland
Copy link
Contributor Author

Thanks for working on this! I feel that a lot of the wording here is vague... is it copied from the existing LCP/element-timing spec? I'd feel more comfortable with using this opportunity to make the spec language more rigorous.

Agreed. Much of the text for this was moved around between specs, and I don't know when it was last reviewed on its own :)
Some of this can be tightened up, for sure. Thanks for pointing out the worst offenders there

index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved

<h4 id="sec-modifications-CSS">Modifications to the CSS specification</h4>

Whenever an <a>image request</a> in an {{Element}} <em>element</em>'s <a>associated background image requests</a> becomes <a>completely available</a>, run the algorithm to <a>process an image that finished loading</a> with <em>element</em> and <a>image request</a> as inputs.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps it's time to upstream these to CSS/HTML soon? LCP is implemented by Gecko so should be good to go...

index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Show resolved Hide resolved
index.bs Outdated
1. If |element|'s <a>set of owned text nodes</a> is empty, continue.
1. <a for="set">Append</a> |element| to |doc|'s <a>set of elements with rendered text</a>.
1. [=set/Append=] |element| to |paintedTextNodes|.
1. Run [=the paint timing steps=] given |document|, |paintTimestamp|,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea I would simply call:

  • Report paint timing given ...
  • Report element timing given...

index.bs Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Outdated Show resolved Hide resolved
index.bs Show resolved Hide resolved
@clelland clelland merged commit ba58148 into main Jan 10, 2024
2 checks passed
clelland added a commit to w3c/largest-contentful-paint that referenced this pull request Jan 15, 2024
This eliminates the dependency on the still-incubating ElementTiming spec, by using concepts newly-introduced into Paint Timing.

The concept of LCP-eligibility is also added, to encapsulate the various heuristics used to filter out elements which are not the primary content of the page (though which would still be considered "contentful" for purposes of calculating First Contentful Paint time.)

Closes: #86, #113
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants