List item inline style fix

[rinkalpagdar]

Fixes #68727

What?

This PR resolves conflict with the default style added for content

Why?

When we register style via register_block_style for list-item it gets conflicted with the default style mentioned in content.scss
We can either remove the default style or reduce the priority or else we can provide !important to our inline style. So it will have more preference.

How?

I have removed the default style causing conflicts.

Testing Instructions

1. Add an inline or inline-block pseudo ::after element via CSS to a core/list-item.

\register_block_style( 
    'core/list-item' , 
    array(
        'default'      => false,
        'name'         => 'acme-list',
        'lable'         => 'ACME List',
        'inline_style' => '.is-style-acme-list { position: relative; } .is-style-acme-list::after { content: "This is a fancy orange box."; background-color: #ffba10; } '
    )
);

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: rinkalpagdar <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: Kallyan01 <[email protected]>
Co-authored-by: djcowan <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

@rinkalpagdar, it looks like @singhakanshu00 is already working on the solution - #68731.

[rinkalpagdar]

@rinkalpagdar, it looks like @singhakanshu00 is already working on the solution - #68731.

@Mamaduka When I started working on the issue. I noticed that no PR or comment were submitted.

[Kallyan01]

@rinkalpagdar , If you started working on the issue earlier, could you please explain why you didn't notify others by commenting on the issue itself that you were working on it ?

This has happened from your side before as well. Here's a reference to the previous incident: link.

cc @Mamaduka

[rinkalpagdar]

@rinkalpagdar, If you started working on the issue earlier, could you please explain why you didn't notify others by commenting on the issue itself that you were working on it?

This has happened from your side before as well. Here's a reference to the previous incident: link.

cc @Mamaduka

Hello @Kallyan01 Sorry for the inconvenience, I don't want to disrespect you but I am new to contribution and if I make a commitment that I am working on a particular issue then I also need to submit the solution as well but I was troubleshooting and I got the solution so have created the PR. If you have noticed this PR, you will get to know that this is completely addressing different part of the parent issue. I have worked on WordPress-develop where the ticket has multiple PR and patch submitted isn't it fine or not? Please guide me. Thanks!

[Mamaduka]

Mistakes happen, so no worries.

• Here, folks usually stick with a single issue/PR combo. Everyone can contribute to the solution by commenting on a PR with helpful details (testing results, code review).
• If the solutions are similar, the oldest PR is kept open and recent duplicates are closed.
• If you're proposing an alternative solution, the difference should be mentioned in the PR description, highlighting the pros and cons of the alternative.

[Kallyan01]

@rinkalpagdar understood your concern. When troubleshooting an issue, after conducting your initial testing, you should have a good idea of whether you'll be able to resolve it. At that point, you can comment your findings in the issue itself. If you’re confident about working on it, you can proceed. If you still not able to fix it you can just opt out by commenting or better start a discussion and take help from other contributors .

Also i think commenting on an issue does not necessarily mean you are obligated to solve it. Since it’s an open-source project, anyone can contribute to resolving the problem.

Adding a comment with your observations is always helpful as it provides valuable insights to other developer's working status, prevents duplication of effort, and ultimately saves time.