Gutenberg: Attributes on a block can't be camelCase

[lamosty]

I found out that if you write your attribute with camelCase (for example postsToShow), the DOM parser won't parse the block correctly. Instead, it will show it as a text in the freeform block:

/cc @youknowriad

[aduth]

Guessing we might just need an i flag here:

https://github.com/WordPress/gutenberg/blob/a33329c/blocks/api/parser.js#L113

Any reason we might want to avoid that? I could potentially see wanting to be strict on the opening marker and slug wp:core/text, but allowing insensitivity for the attributes.

cc @nylen

[nylen]

In the interest of keeping this as specific as possible until we know we need to do otherwise, let's just add A-Z to the attribute portion (and tests to make sure both parsers can handle this correctly).

Now that I'm looking at that regex again, we support attribute names containing - and _, but we don't have tests for these cases either. As part of this task, we should standardize on a convention and add more tests.

[dmsnell]

When I wrote the original parser I was looking towards the HTML spec and it indicates case insensitivity. I stopped short of implementing the spec since we didn't know what we wanted but it seems reasonable to adopt that same specification here too.

https://www.w3.org/TR/html51/syntax.html#name

[afercia]

Worth nothing that, as far as i know, the convention for HTML attributes in core is lowercase and hyphen, nothing else. I'm not saying that it's applied consistently 🙂

[nylen]

The major advantage of using camelCase attributes is that we don't have to do some fancy mapping to transform them into the property names we'll want in the JavaScript code.

The major disadvantage is that it is a further deviation from HTML; personally I think this is OK.

-1 on case-insensitivity.

[afercia]

@nylen was so kind to clarify to me these attributes are used inside HTML comments so I guess we can use whatever we want and they don't need to follow the WP HTML coding standards.

[dmsnell]

further deviation from HTML

HTML does not require any case on attributes. they are case insensitive as noted in the spec I linked. That means, if we use camelCase it won't be diverging from HTML at all.

With HTML the _names_ of the attributes have a case but the syntax is case-insensitive and we have a guarantee that no two attributes exist whose names only differ in case.

[afercia]

HTML does not require any case on attributes.

WordPress does. See: https://make.wordpress.org/core/handbook/best-practices/coding-standards/html/#attributes-and-tags

But, as noted above, since these are going to be within HTML comments, I guess ti really doesn't matter.

[dmsnell]

WordPress does

perfectly fine, but I was pointing out in response to the claim that this is not an HTML constraint

[dmsnell]

Closing since the DOM parser is gone. Let's reopen if we want to add the constraint that camelCase shouldn't be allowed. We have other discussions about data format too