I forgot about set_attribute and remove_attribute – just accounted for those two.

With set_attribute there's a question of what should happen here:

$p = new WP_HTML_Tag_Processor( '<div DATA-enabled="true">Test</div>' );
$p->next_tag();
$p->set_attribute( 'data-ENABLED', 'abc' );

I went for <div data-enabled="abc">Test</div>' – what do you think @dmsnell ?

@adamziel in keeping in line with touching as little as possible I propose it should work like so:

• get_attribute() is case insensitive
• remove_attribute() is case insensitive
• set_attribute() respects what it was given

So for set_attribute() we can store the given name with its unique casing, but use the comparable case-insensitive check to see if we are replacing or adding a new attribute.

Updating the value of an attribute that already exists could arguable leave the old name which would touch the HTML less than replacing the name would, but then that takes away the ability to enforce a new naming casing on write.

HTML specifies how we interpret those attributes but it doesn't mandate that attributes are written in lowercase.

@adamziel I pushed a commit implementing the behavior I suggested. we can remove those commits if you think it's a mistake.

in addition I updated the comments to quote directly from the spec and linked to a different section which discusses the meaning of the attribute name instead of the description of how to parse them. figured that might be more normative.

@dmsnell I wholeheartedly agree with your reasoning.

I've applied some minor polish (6bd2b93, b5babb1). I'll merge once CI goes green (unless there's any last-minute change requests) 😄

Thanks both of you!