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

Ignore 0xHHH and 0xHHHH hex colors #143

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

thomcc
Copy link
Contributor

@thomcc thomcc commented Aug 2, 2021

I've genuinely never seen the 3 and 4 character 0x-prefixed version used to represent a color (and have worked with colors represented as integers a lot). It feels like it was included just because # supports them (which is good — that is much more common).

IMO, as it is it triggers far too often. Stuff like x = n & 0xffff and the like, which is bordering on silly.

@ferretwithaberet
Copy link
Collaborator

ferretwithaberet commented Aug 2, 2021

Instead of outright removing them. Would you mind making this a setting? In my opinion this solution would make everyone happy.

@thomcc
Copy link
Contributor Author

thomcc commented Aug 2, 2021

Instead of outright removing them. Would you mind making this a setting? In my opinion this solution would make everyone happy.

Sure, but is there anybody who actually uses it that way? I'd be surprised.

I don't mind making it a setting though.

@ferretwithaberet
Copy link
Collaborator

Instead of outright removing them. Would you mind making this a setting? In my opinion this solution would make everyone happy.

Sure, but is there anybody who actually uses it that way? I'd be surprised.

I don't mind making it a setting though.

I cannot know as we do not collect any data on how the extension is used. But like you said

It feels like it was included just because # supports them (which is good — that is much more common).

If # syntax supports it, it means that it has use cases, so it should be supported. Some people might actually use it, I think I even used it for white/black (#fff or #000) because it is easier to write.

@ferdnyc
Copy link

ferdnyc commented Dec 15, 2023

@ferretwithaberet

It feels like it was included just because # supports them (which is good — that is much more common).

If # syntax supports it, it means that it has use cases, so it should be supported. Some people might actually use it, I think I even used it for white/black (#fff or #000) because it is easier to write.

See, that's the one part of this argument that doesn't make sense to me. Just because #rgb and #rgba are supported by the CSS parser as shorthands (and nobody has ever been suggesting that support for those patterns be removed), that doesn't mean that 0xrgb and 0xrgba are ever used in code to store color values.

I guarantee that CSS parser implementations that read an #rgb string store that value in-memory as 0xrrggbb (or even 0xrrggbbFF), as nobody in their right mind would pack the color value of 0xrrggbb into 0xrgb — that's an optimization for humans, not for code.

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