-
Notifications
You must be signed in to change notification settings - Fork 47.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restores 'border' when 'borderColor' is removed #2013
Conversation
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks! |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
Not sure what the devs feel, but it's technically invalid to have both |
There are no additional DOM updates. When you remove 'borderColor' leaving 'border', the real DOM removal is suppressed (line 436 of my ReactDOMComponent.js) and only 'border' is reintroduced. |
@syranide Is it really invalid? I often write something like
to get borders on only top and bottom. |
@spicyj That's why I added "in the style object" :).
... and only the last line would end up being used, this is not something we can offer (because: map) and there's no reason to either. There's no harm in supporting this I imagine, but it does add bytes, it adds redundant bytes to the generated HTML too and it does have a non-obvious performance implication (apart from actually adding more styles to be set initially too):
... adding/modyfing/removing only So there's no doubt to me that this would be the best/correct solution, if for example we would parse So I wonder, is there any "valid" use-case that would require this, that would offset the hidden danger? EDIT: As spicyj mentioned, being able to set all borders and remove one is a pretty common pattern in CSS, so there's that... |
The test shouldn't mutate. This pattern currently relies on enumeration order. This might not be possible in the future (e.g. using ES7 value types). We might need to rely on alphabetic order. We should consider not allowing conflicting style rules at all. |
Thank you for sending the PR! It has not been updated in response to the feedback for quite a while, so I am closing. For an up-to-date issue about this with a summary and the discussion of the desired behavior, please see #6348. We hope to see you contributing again! |
STYLE: 'border' already contains color component. So, after 'borderColor' removal, the style should fall back to color value taken from 'border'. Here is the fiddle of malfunction: http://jsfiddle.net/a4grcdtw/