Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Number and Boolean block attributes stored as an HTML attribute should be parsed properly #13965
This pull requests fixes two issues I identified while storing a block attribute in an HTML attribute:
How has this been tested?
I created a simple block and stored boolean and number attributes in HTML attributes. Before the PR, Gutenberg complained about expected and actual values not matching. With this PR, Gutenberg pulls the proper values and things work as expected.
Types of changes
I think both changes are Breaking changes, as they change Gutenberg's behaviour regarding Boolean and Number HTML attributes.
Related: #10338 (Where most type coercion was removed)
With that in mind, do you have an idea for how it could be rolled out?
Minding that today, the option remains to simply use the comment serialization offerings to preserve intended type (i.e. omit
There are multiple discussions here.
First, there's #9634. I personally think that Gutenberg's management of
#10338, on the other hand, proposes a more ambitious solution. I don't feel qualified enough for discussing type coercion in general...
From my point of view, storing primitive values such as a string, a number, or a boolean in an HTML attribute should be possible. My PR addresses numbers and booleans only and I think does so in a predictable and understandable way:
I know this PR proposes some Breaking changes, but I don't think any developer is currently using
* The only exception to this rule are boolean attributes. The mere presence of a boolean attribute (e.g.
It does, though. Assigning a value of
Given the inline examples provided in
Aligns to the actual DOM behavior: https://codepen.io/aduth/pen/PVgpeG
I bring it up because largely there's no established protocol for how to introduce breaking changes. It would be one thing if it were something classified as a bug, but it caught my attention being self-described as breaking.
Indeed. According to the spec:
Some attributes play the role of boolean variables. Their appearance in the start tag of an element implies that the value of the attribute is "true". Their absence implies a value of "false".
In my opinion, though, something like
But look at this other example: https://codepen.io/anon/pen/jdRwdr. An attribute such as
I described this as a breaking change because if there was one single developer that had ever written something like
Maybe this should only apply to attributes named
How do you feel about the proposed PR? Does it make sense to move ahead with such changes? Should anybody else join the discussion?
Editor Weekly Chat Wednesday, September 11, 2019, 03:00 PM GMT+2 in #core-editor