-
Notifications
You must be signed in to change notification settings - Fork 28
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
Conversation
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.
There was a problem hiding this 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> |
There was a problem hiding this comment.
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"> |
There was a problem hiding this comment.
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?
There was a problem hiding this 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: |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
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|, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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...
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 :) |
|
||
<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. |
There was a problem hiding this comment.
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
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|, |
There was a problem hiding this comment.
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...
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
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