-
Notifications
You must be signed in to change notification settings - Fork 38
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
Introduce HTML Processor #1200
Comments
Heads up @WordPress/docs-issues-coordinators, we have a new issue open. Time to use 'em labels. |
Trac: https://core.trac.wordpress.org/ticket/58517 But mentioned in another trac ticket that this one needs one https://core.trac.wordpress.org/ticket/58961#comment:9 so I commented there asking about it newly identified dev note Owned by: dmsnell |
Draft shared on ticket. Adding on tracker to make more visible. Please highlight in core for tech review. |
Draft: https://make.wordpress.org/core/?p=109160&preview=true The dev note looks good to me. The only comments I have are that based on review of other dev notes, I think when tags are mentioned like div and img, we typically use inline code tag so it appears like Also, would you agree this should go in the field guide? |
Just reviewed:
|
@codente Yes should go into the Field Guide. |
seems fair, though for context I adopted that expression style based on a combination of WordPress requiring it internally and based on the nomenclature in the HTML literature. it's been a hard call determining which conflicting styles to follow. I'm not sure why the tag syntax isn't allowed inside WordPress, unless it has to do with preventing rendering issues when generating documentation. more importantly but tangentially, and something I've been trying to do consistently with the HTML API is speak of elements when talking about the DOM nodes or what is in a page, e.g. an IMG element, and of tags only when talking about the text/strings in HTML. whereas there's an whatever people want here is fine with me, though if there's doubt about the requirement, I would like to see broader adoption of "DIV element" phrasing in WordPress literature. |
@bph I added based on the fact that this is a dev note for a release and for something in a specific component I understood the guidelines to indicate that both tags should be there, as the example links to it was also confusing whether I should add this is unrelated to the dev note for the HTML Processor, but I wasn't sure where else to leave this feedback. |
Another question I had is whether it will be possible to link to the docs for this class before the dev note publishes. I'd really like to send people to the class documentation as that's more comprehensive and full of examples to follow. Is that going to be available or do we have to skip the docs link for this one? |
I have just asked your question on tags to @abhansnuk. Below is her reply: Where a dev note is a mixed dev note, eg performance, and covers a number of components, it is unclear whether we need to tag all the components or not use the component tag. We have added this to the documentation tracker to find the definitive answer, and then apply this to all published dev notes where this query applies. Also to the documentation for those doing the release, and updating the page on dev notes in the Core Handbook. Thanks Dennis for highlighting that it is unclear in the Handbook. |
Is there a particular description you think would be useful for developers for this in the Field Guide? If there is more information on the class documentation and full examples to follow, then it would be a useful link to add to this dev note. Thank you @dmsnell |
Copying for Abha:
Really enjoyed reading this dev note, clear and easy to follow. Thanks so much @dmsnell, and to @bph and @codente too. I think it would make a good follow up in the dev blog showing its usage too. |
#1200 (comment) |
there's no list of examples, just a few links to existing dev notes. I think a single list of a few cases with all appropriate tags could go a long way. moreover, two specific things that confused me:
The dev note tags make it possible to filter Make posts to see all dev notes, updates to a particular WordPress release, or updates to a particular component. Examples:
|
I am learning every day :-) I didn't retain the information from the guidelines as to a specific component being tagged. But I would think those are the components from this page only. The devnotes-[version] might have been from my rookie dev notes wrangling days. I used in 6.0, I think, and that stuck around. Back then I didn't know about that you could to daisy-chain of tags to /tag/devnotes+[version] Now devnotes-[version] actually feels redundant. |
My interpretation is that if we miss out the tag with both dev notes and the 6.4 tag, then people clicking on 6.4 will have a list of everything tagged 6.4, so much more than the dev notes. To me the combination of these tags allow the person to get a filter of dev notes relating to 6.4 only. This is useful if they are interested in dev notes wider than a single component. In that case, the dev notes query with the component name would not be sufficient. Equally there may be a person who wants to only see dev notes by a particular component. |
"The one example given, using 5.5 as a version number, contradicts the tag seen in the links and existing dev notes, which use 5-5. I think that WordPress automatically converts the . to a -, but it would be helpful if those were consistent. the block editor shows dev-notes-6.4 yet the post renders with dev-notes-6-4." The answer to this can go in the documentation gathering from this release relating to docs. This can also support updating the dev notes and Field Guide pages in the core handbook. Thank you for highlighting. Can I clarify, @dmsnell you are suggesting when typing in the tag, dev-notes-6-4 should be used instead of the point in the version number? This would then give consistency. Thank you. |
@dmsnell in the Field Guide, we usually put a short description with the embed/link to the dev note. Something like: "WordPress 6.4 includes continued development of the HTML API, including the introduction of a minimal HTML Processor with the concept of breadcrumbs and makes it possible to, for example, search for images that are direct children of a DIV. Also included in 6.4, is the addition of a couple of CSS/class helpers in the Tag Processor which will make it possible to search for a tag containing more than one class name, or to search for a tag not containing a given class name." What are your thoughts on the above? Feel free to provide your own short description instead if you think something else would be more beneficial. |
Here to add a +1 to this comment from @nalininsbs. Daisy-chaining is helpful, but being able to click on a single tag for release specific dev notes is super helpful, since there's no intuitive visual way to daisy chain that I'm aware of in the Make blogs. |
I'm not sure I totally understand what you're asking, but the HTML Processor definitely belongs to the HTML API, one of the components in that list.
I expect we all are. I sure am. These are all my own observations and interpretations, by the way. I have no idea what's right or if the documentation is out of date.
on this point I'm not sure. all I'm saying is that it's a bit confusing to be instructed to enter
@codente sounds great! thanks for putting that together.
Some drive-by observations on this: I hear the value statement of doing this, and it may be warranted in this very limited case, but precomputing this daisy-chaining can also lead to confusion, which I believe it has in this case. I wonder if there's a more valuable approach to making it easier to learn how to limit the posts in the Make blog so that it's less confusing - teach people as they use the site. Obviously it's not practical to create tags for every combination of tags one might want to daisy-chain. Maybe this is a very rare and unique special case though 🤷♂️ @nalininsbs just to ensure we're on the same page, in the example snippet I shared above, my goal was to communicate that these tags are additive. a dev note would have one, two, or three tags depending on if it's generic, part of a release, part of a component, or part of a release and a component. with three tags we get four different searches: all dev notes, all dev notes for the REST API, all dev notes for 6.4, all dev notes for 6.4 that are part of the REST API. my wording was only suggestive for the concept and is probably unclear. |
Thank you for the answers, appreciated. @dmsnell . On one aspect, is the rest of the dev blog now ready to be published? The tag issue can be resolved later on the post. The Field Guide will Georgie from its inclusion at this stage. Thank you for all your input on the tag issue and the last clarification too. |
Perhaps if other people think it is; I'm content with it, but I don't know where the review left it. |
Tags issue will be further discussed post Field Guide. Published link: https://make.wordpress.org/core/2023/10/21/updates-to-the-html-api-in-6-4/ |
Thank you @nalininsbs ! |
No description provided.
The text was updated successfully, but these errors were encountered: