Skip to content
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

Keep shorthand color form the same way as named colors are kept. #2643

Conversation

SomMeri
Copy link
Member

@SomMeri SomMeri commented Jul 19, 2015

Keep shorthand color form the same way as named colors are kept. Fixes #2481 - Interpolated selectors and three letters long id selectors.

@seven-phases-max
Copy link
Member

See my last remark at #2481. I suspect we also need to rework the code around "Invalid HEX color code" then (I'm not yet sure how exactly though, most likely the check is just to be removed - so that any #* which is not a hexcolor to be parsed as Anonymous).

@lukeapage
Copy link
Member

I think this is okay but not a a bugfix for #2481 if that makes sense - @seven-phases-max I think this keeps coming back to my wanting a proper way of writing a selector and not mixing css values and selectors. The main problem with that was last time I brought it up no-one could agree a syntax. I liked $() other people not.

@seven-phases-max do you agree this should go in even though its not a "proper" fix?

@seven-phases-max
Copy link
Member

@lukeapage Yes, I'm actually fine with this change (and for my remark I guess I'll just try to submit a separate patch if I have any good idea).

lukeapage added a commit that referenced this pull request Sep 9, 2015
…to-selector-1481

Keep shorthand color form the same way as named colors are kept.
@lukeapage lukeapage merged commit 8a135bd into less:master Sep 9, 2015
@seven-phases-max
Copy link
Member

I just realized that this PR does something more then just "keep shorthand value". Obviously it preserves the original format as a whole (e.g. including lower/uppercase stuff) thus resulting in issues like gruntjs/grunt-contrib-less#295.
It's fine (not really an issue) but should not we backpatch the changlog then to make it more obvious? (I'm not sure if this normal practice).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants