search

joernweissenborn / lcars

CSS Framework to style web pages like the fictional computer operating system of a popular sci-fi franchise.
http://joernweissenborn.github.io/lcars/
MIT License
334 stars 80 forks source link

doubled color class selector, like important #40

Closed xenziffen closed 4 years ago

xenziffen commented 4 years ago

34 The goal of this branch is to increase lcars color selector specificity.

Reading a bit more, it is recommended that the selector simply repeat the same class name. That means it will match "twice as much" as any other color rule with only one class name or any element types.

I recommend we try this to see if it can be accepted into the project.

xenziffen commented 4 years ago

OK. I've tested this on desktop and mobile. Seems to be working as expected. Using double selector names is powerful. It takes selectors with three class name matches or any id to override color now. But is still reasonable. For the .button:active I doubled up 'button', even though it naturally had two matching classes for being both .lcars-element and .button. So now button :active matches 3-classes, 1-element match. The style inspector showed in some cases the browser gave pseudo states priority by forcing the pseudo class selector to be important, but I seen no reason to trust it.

Checked on Firefox Chromium Mobile Chrome Mobile Android webview

jrwarwick commented 4 years ago

Fascinating. I was not aware of the technique, indeed I wasn't even aware of the concept of doubling the class selector as a valid selector expression at all. Good work, @xenziffen . For the convenience of more casual consumers, would you please perform the Stylus compile and commit that as well? I know its a bit messier in terms of diffs and PRs, but the trade off is sort of works-as-advertised-out-of-the-box, even for folks who will just be grabbing the CSS and throwing away the Stylus.

xenziffen commented 4 years ago

Sure thing. Didn't know if you guys had a different process for builds in place, so I only touched what was necessary.

The cloned build is kinda annoying for me me. It's not using the latest Gulp 4, so I have to switch anytime I want to build in the branches from this project.

For my own stuff I refactor gulpfile.js to Gulp4 easy enough. But there's a pretty big breaking change between Gulp 3 and Gulp 4, having to do with callbacks for the serial and parallel setups Gulp4 requires. The question then is, should I maybe create the issue and a branch to update the gulpfile.js? Do you think upgrading Gulp is in the cards?

jrwarwick commented 4 years ago

I have to admit that I'm totally new to gulp and the whole nodejs world, really. I'm glad you mentioned this. I wasn't aware of the obstacles. If gulp 4 is the future and has wide adoption, I would support that upgrade.

Let's pose the question to Jörn through a new issue. Would you create a new issue with that same explanation?

jrwarwick commented 4 years ago

it looks like the color correction merge slightly collided with this PR. But the gulp upgrade should now be in place. would you rebase and commit to clear up the conflict ? I think we'll be in a place to merge this in.

jrwarwick commented 4 years ago

I think we are really close to our first release. Would you merge/rebase from master, recompile the CSS and commit, @xenziffen ? This is a really excellent pull request, but some other commits that got in ahead of it created minor conflicts.

xenziffen commented 4 years ago

Hey Justin,

I'm just getting my environment setup again. Switched distros. So all that is needed is someone to build the CSS files and check them in from a repository that is down-tree from the previous accepted commits?

On Thu, Apr 16, 2020 at 10:27 AM Justin Warwick notifications@github.com wrote:

I think we are really close to our first release. Would you merge/rebase from master, recompile the CSS and commit, @xenziffen https://github.com/xenziffen ? This is a really excellent pull request, but some other commits that got in ahead of it created minor conflicts.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/joernweissenborn/lcars/pull/40#issuecomment-614788510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3PFB7224FA7BQKFKWTV43RM45YHANCNFSM4K6NAODQ .

jrwarwick commented 4 years ago

Although I'm not totally familiar with that terminology, it's a descriptive match for what I see in the conflict report. So I'll give a weak "affirmative".

--Justin

On Fri, Apr 17, 2020, 16:46 xenziffen notifications@github.com wrote:

Hey Justin,

I'm just getting my environment setup again. Switched distros. So all that is needed is someone to build the CSS files and check them in from a repository that is down-tree from the previous accepted commits?

On Thu, Apr 16, 2020 at 10:27 AM Justin Warwick notifications@github.com wrote:

I think we are really close to our first release. Would you merge/rebase from master, recompile the CSS and commit, @xenziffen https://github.com/xenziffen ? This is a really excellent pull request, but some other commits that got in ahead of it created minor conflicts.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/joernweissenborn/lcars/pull/40#issuecomment-614788510>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AG3PFB7224FA7BQKFKWTV43RM45YHANCNFSM4K6NAODQ

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/joernweissenborn/lcars/pull/40#issuecomment-615512804, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALAR5FZCQVFNMVKFDBP2RLRNDS5JANCNFSM4K6NAODQ .

jrwarwick commented 4 years ago

I couldn't find the "right way" to just do this compile myself and commit to the PR. I was able to use the web interface to make direct edits to the conflicting files, though. The edits will clear the conflicts, but they will be slightly out of sync and not contain all the appropriate rules resulting from merge. But I think this is ok as a work around. I will just recompile in the course of a subsequent PR.