Original text:
which is not yet in the tree.  Such elements are added to the tree with the requested priority. <del> When a prioritized element is first created it has a default inital </del>  weight of 16 and a default dependency.  Requests and placeholders are <del> dependent on the root of the priority tree, pushes are dependent on </del>  the client request on which the PUSH_PROMISE frame was sent. Requests may override the default intial values by including a PRIORTIY frame (see frame-priority) at the beginning of the stream. <del> Pushes and placeholders may be later updated by sending a PRIORITY frame on the control stream. </del>  5.3.1.

Reviewer comments:
Maybe takes things too far, please discuss.
Draft 17 says If I understand H3 Placeholders correctly, the PRIORITY frame would be used to set their priority too. Perhaps we can say: .
To me it seems that the current text is more accurate. While a PRIORITY frame might use a placeholder to designate the target, what is actually prioritized is the stream that carries the response. The transmission of the placeholder itself is never prioritized.
But the PRIORITY frame contains the Prioritized Element ID field, that allows us to set the priority of Placeholder type.
Yeah, my view is that it is an act of prioritizing a stream by specifying a placeholder ID that maps to the stream. Section 5.3 talks about prioritizing "streams".
That's a good observation, so I'd go further to say that IMO the textual description of H3 prioritisation is not completely aligned with the protocol mechanisms. Cue NAME to tell me I am completely off the mark :)
Also, the table of prioritized element types in seems to be duplicated
The two tables in section 4.2.3 are slightly different.
Correct, I just independently spotted that. Its logical but a bit annoying
makes some basic edits to section 4.2.3, adding Table captions and linking to them from the paragraph above. It reworks 5.3 slightly to reframe the language toward describing a tree of abstract elements but still provides concrete examples of request prioritisation.
Yeah, there was originally one table and I had to split it to accommodate the current design. If anyone sees an elegant way to recombine them, I'm fully supportive.
I thought perhaps make the labels multi line and then combine the last two columns of the second table onto the first. So there would be two colums containing two sub columns each, plus the left most bits column. I don't know the Markdown foo to make that happen though.
NAME My bad. I was confused. I now understand the issue and think that the PR will provide us the necessary fixes.
A comment on this text: we should be prioritizing requests and maybe pushes, not streams.
That's a fair point I'll see if I can incorporate that into the PR
Yes, I like this formulation better.

Revised text:
which is not yet in the tree.  Such elements are added to the tree with the requested priority.  <ins> When a prioritized element is first created, it has a default initial </ins> weight of 16 and a default dependency.  Requests and placeholders are  <ins> dependent on the root of the priority tree; pushes are dependent on </ins> the client request on which the PUSH_PROMISE frame was sent. Requests may override the default intial values by including a PRIORTIY frame (see frame-priority) at the beginning of the stream.  <ins> These priorities can be updated by sending a PRIORITY frame on the control stream. </ins> 5.3.1.