This is perhaps a minor point, and I only noticed it because I wanted to quickly hide a few fields that site editors weren't ever going to use. But the Twitter cards–related fields have CSS classes on their divs that are invalid. For instance:

form-item-metatags-twitter:creator:id-value
form-item-metatags-twitter:image-value
form-item-metatags-twitter:image:width-value
form-item-metatags-twitter:player:stream:content-type-value

None of those colons are valid in the CSS class names. I'm guessing the field names are just being converted to class names without replacing those colons with hyphens (or something).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rootwork’s picture

Title: Twitter card field CSS class names are invalid » Twitter card, DC field CSS class names are invalid

Actually I just noticed the Dublin Core fields have invalid class names too:

form-item-metatags-dcterms.subject-value
form-item-metatags-dcterms.contributor-value
form-item-metatags-dcterms.format-value

(etc.)

The periods aren't valid in CSS class names (as they have a functional purpose in stylesheets).

rootwork’s picture

Title: Twitter card, DC field CSS class names are invalid » Vertical tab class names contain invalid characters
Issue summary: View changes
Status: Active » Needs work
FileSize
725 bytes

I did some more digging. It looks like it's Drupal's formbuilder itself, which only replaces the characters " ", "_", "[", and "]".

I looked through metatag.module, metatag.vertical-tabs.js, and metatag_twitter_cards.metatag.inc and couldn't figure out where it's being called precisely (this isn't my strong suit).

For reference, I'm attaching what would be a patch of the core formbuilder. If Metatag's maintainers think this should actually be handled in core itself, I'll change the project, but really this is just to move this issue along and provide the context so it can be addressed in Metatag.

DamienMcKenna’s picture

Status: Needs work » Needs review
DamienMcKenna’s picture

Status: Needs review » Active

Correcting the status - the patch isn't for Metatag.

DamienMcKenna’s picture

Version: 7.x-1.0-beta7 » 7.x-1.x-dev
DamienMcKenna’s picture

Status: Active » Needs review
FileSize
1.24 KB

This could be handled in Metatag by assigning a #name attribute to the form fields, right?

DamienMcKenna’s picture

Issue tags: +Accessibility

Status: Needs review » Needs work

The last submitted patch, 6: metatag-n2058569-6.patch, failed testing.

The last submitted patch, 6: metatag-n2058569-6.patch, failed testing.

DamienMcKenna’s picture

The change breaks all the things. Ugh.

DamienMcKenna’s picture

We might have to rename all of the meta tags in order to fix this, and I'd prefer not to have to do that.

Heine’s picture

According to the CSS spec:

In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters U+00A0 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, two hyphens, or a hyphen followed by a digit.
Identifiers can also contain escaped characters and any ISO 10646 character as a numeric code (see next item). For instance, the identifier "B&W?" may be written as "B\&W\?" or "B\26 W\3F".

Either one of the following selectors is valid:

.form-item-metatags-twitter\:creator\:id-value
.form-item-metatags-twitter\3A creator\3A id-value
rootwork’s picture

I guess, but is that really where we want to leave it? We don't want to just replace those characters?

I suppose if "breaks all the things" is the only other option then the answer is that we leave it. But I don't know any other contrib modules, certainly not as big as Metatag, that require themers to escape the class names it outputs.

DamienMcKenna’s picture

Status: Needs work » Postponed

@rootwork: I really do sympathize with the issue. I've opened a core issue to see if we can fix the issue there: #2741917: theme_form_element can result in field classes that contain invalid/inconvenient characters

rootwork’s picture

Thanks! I'll follow over there.

rootwork’s picture

If anyone else encounters this issue, I've posted an updated core patch at #2741917: theme_form_element can result in field classes that contain invalid/inconvenient characters.