Dev gui - Darkmode using HSL Hue

[gigamaster]

What type of PR is this? (check all applicable)

• ✨ Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• ♻️ Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI
• 📦 Chore (Release)
• ⏩ Revert

Description

Feature: Improve overall app design (look and feel) #539

1. Images svg optimization.

2. Darkmode using HSL Hue degree on the color wheel from 0 to 360 ie. 0 is red, 120 is green, and 214 is blue.
   Default css var --hue: 214;

Todo : add an input range under "dark theme" in main menu and store Hue value in localStorage.

Related Tickets & Documents

WIP #539

Mobile & Desktop Screenshots/Recordings

Added tests?

• 👍 yes
• 🙅 no, because they aren't needed
• 🙋 no, because I need help

Added to documentations?

• 📓 docs (./docs)
• 📕 storybook (./storybook)
• 📜 README.md
• 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?

No.

[optional] What gif best describes this PR or how it makes you feel?

Dark Mode minimalist theming. Todo : rename CSS vars and improve colour scheme with high visual contrast.

[netlify]

✅ Deploy Preview for livecodes ready!

Name	Link
🔨 Latest commit	06a877e
🔍 Latest deploy log	https://app.netlify.com/sites/livecodes/deploys/6701c32f180629000866fa60
😎 Deploy Preview	https://deploy-preview-630--livecodes.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[hatemhosny]

Thank you @gigamaster
That's very nice 👌

I will have a good look and let you know.

Meanwhile, please run npm run fix to fix linting and formatting errors. Then we can look later into failing e2e tests.

Very grateful. Thanks.

[gigamaster]

Thank you @gigamaster That's very nice 👌

I will have a good look and let you know.

Meanwhile, please run npm run fix to fix linting and formatting errors. Then we can look later into failing e2e tests.

Very grateful. Thanks.

Hi @hatemhosny

I was surprise that the Draft pull request to share the work-in-progress did trigger automated workflows 🤨
The automated development workflows are great and the "Deploy Preview" is really 😎
The purpose of this Draft PR was to seek feedback, discuss design decisions, iterate, and refine the changes before a pull request.
For example, moving UI icons to CSS using mask to make it easier to customize colors and sizes.
Use HSL Hue, an input range and save preferences to localStorage or make custom color palettes.
Then, delete code comments based on decisions made and run tests.
Have fun. Cheers ^_^/

[hatemhosny]

No worries, @gigamaster

I understand this is still WIP. I did trigger the automated checks just to get an idea.

I will go through the changes and design decisions and give feedback.

One note for now:
A better way than manually storing this setting to localStorage, is to add a config option (e.g. themeAccent or themeHue). This automatically saves it locally, and also allows other scenarios, like setting it in query params and setting/getting it in SDK even during runtime.
That's an easy change that I can guide implementing.

Overall, I really like what you are doing here. I'm a bit busy with some personal commitments for the next few days. I will have a good look when I have a chance and get back to discuss with you here.

Thank you.

[hatemhosny]

Hi @gigamaster

I had a good look around. I very much like your approach.
Using HSL hue and CSS icons are very neat.
I like the ability to change the colors by changing a single CSS variable.
Great work. Thanks a lot.

I do have some comments. A few are related to UI & colors (e.g. contrast of text/images with background, etc.). I think I would keep these till you finish because you are probably going to improve them anyways. You are much better than me in this area.

Other comments:

• I planned doing this for a while, maybe it's time now. I want to change all clickable elements to <button> elements (to improve semantics, improve accessibility and keyboard navigation). We can still use CSS icons by either changing the spans to buttons or putting the spans inside the buttons (which is still valid HTML).
• e2e tests failed mainly because clicking the run button using this selector ([alt="Run"]) no longer works. We need to change the selector to something that would match any of these 2 buttons: this and that. Maybe add a data attribute.
• Would you elaborate why we need to add these gitattributes? What was the problem you faced? Would * text=auto be enough? Please note that I use Windows, but also want to allow contributors using other OSes to work with no problems.
• One last stylistic comment (just a personal opinion): I preferred darker color for menus and models like you did here, while keeping the hue for accents like hover, active items, buttons, etc. What do you think?

Otherwise, please go on. I do like your approach.
Obviously, please feel free to ask if you have any inquiries.
Thank you.

[gigamaster]

Hi @hatemhosny

I'm glad for the feedback.

I had a good look around. I very much like your approach. Using HSL hue and CSS icons are very neat. I like the ability to change the colors by changing a single CSS variable. Great work. Thanks a lot.

I do have some comments. A few are related to UI & colors (e.g. contrast of text/images with background, etc.). I think I would keep these till you finish because you are probably going to improve them anyways. You are much better than me in this area.

Ok then lets try to keep it simple...

Other comments:

• I planned doing this for a while, maybe it's time now. I want to change all clickable elements to <button> elements (to improve semantics, improve accessibility and keyboard navigation). We can still use CSS icons by either changing the spans to buttons or putting the spans inside the buttons (which is still valid HTML).

Great, I'll dig into the code to see how changes can be made.

• e2e tests failed mainly because clicking the run button using this selector ([alt="Run"]) no longer works. We need to change the selector to something that would match any of these 2 buttons: this and that. Maybe add a data attribute.

Noted.

• Would you elaborate why we need to add these gitattributes? What was the problem you faced? Would * text=auto be enough? Please note that I use Windows, but also want to allow contributors using other OSes to work with no problems.

Oohh... gitattributes was merged from my workspace mockup/prototype/test : android -> old imac -> windows
In general, if it works on the old machine, it should work fine everywhere. Guess, it can be removed.
I did not find any particular issue so far, livecodes setup is highly efficient.

• One last stylistic comment (just a personal opinion): I preferred darker color for menus and models like you did here, while keeping the hue for accents like hover, active items, buttons, etc. What do you think?

Otherwise, please go on. I do like your approach. Obviously, please feel free to ask if you have any inquiries. Thank you.

Dark/light mode implements a color-layer for the livecodes app and color-hue on elements only.
I tried CSS variables inheritance and fallback from editor, but it turned out to be confusing since users can choose a different editor... Also, the settings menu is split with a new settings-ui menu.
The menus could be over the top i.e : file, settings, utils, help, more on this later.
Right now, the menu setttings and settings-ui could be placed next to the logo
while keeping Run and Share on the left.

Livecodes UI Modal

Livecodes UI Dialog

Livecodes UI Menu Settings

[hatemhosny]

Oh wow!
That looks beautiful 💯

I tried CSS variables inheritance and fallback from editor, but it turned out to be confusing since users can choose a different editor

Yes, currently users can choose a light editorTheme with a dark app theme. We might change this later, but this is the current behavior.

Also, the settings menu is split with a new settings-ui menu.

This is reasonable. Actually the left column of the "App menu" is related to the current project (except the login/logout link). While the right column is related to overall app settings. So it may be reasonable to split them to 2 menus: "Project" and "App Settings" (also with login link)

The menus could be over the top i.e : file, settings, utils, help, more on this later.
Right now, the menu setttings and settings-ui could be placed next to the logo
while keeping Run and Share on the left.

I will need to see a demo of this to make up my mind. Please note that LiveCodes does not provide multi-file support, so having a menu called "file" would probably not be suitable. "Project" would be a more suitable name.

Whenever possible, please push your changes, so that I can try it in the deploy preview. It does not need to pass the tests for now.

Thank you :)

[hatemhosny]

@gigamaster
One more thing that is not urgent at all, but I thought it might be useful to tell you in case you want to take it into consideration.
There is a quite significant work being done here to provide i18n support in LiveCodes so that the app would be multi-lingual. That feature is approaching to be ready.

A lot of LiveCodes users are Arabic speakers. So it would be great if we can also offer RTL layout.

This does not need to be in this PR. Just wanted to give you heads up.

Thank you :)

[gigamaster]

@gigamaster One more thing that is not urgent at all, but I thought it might be useful to tell you in case you want to take it into consideration. There is a quite significant work being done here to provide i18n support in LiveCodes so that the app would be multi-lingual. That feature is approaching to be ready.

A lot of LiveCodes users are Arabic speakers. So it would be great if we can also offer RTL layout.

This does not need to be in this PR. Just wanted to give you heads up.

Thank you :)

Hi @hatemhosny

So, to avoid any issues with editor theme selection, dark mode applies only to the application UI layer. By the way, I also noticed that Luna console and notifications are configured with light theme by default - maybe this can be changed to match the selected editor dark theme and, or app darkmode !?

After a quick check of i18n support branch, it doesn't seem like it's a problem to adapt and merge the UI. You can focus on i18n and later merge dark mode. Let me know when it's ready for translations.

About RTL layout - css dir pseudo-class might do the trick, maybe similar to html.dark, ie. html[dir="rtl"] to provide optional direction. I'll check browser support and test.
https://caniuse.com/css-dir-pseudo
https://caniuse.com/?search=direction

[hatemhosny]

So, to avoid any issues with editor theme selection, dark mode applies only to the application UI layer.

Yes, let's keep it like this for now.

By the way, I also noticed that Luna console and notifications are configured with light theme by default

You are correct. I have opened a PR in your repo to fix that. You may want to customize notification colors here. You can get the active theme using getConfig().theme.

After a quick check of i18n support branch, it doesn't seem like it's a problem to adapt and merge the UI. You can focus on i18n and later merge dark mode. Let me know when it's ready for translations.

That's great. Thank you.

About RTL layout - css dir pseudo-class might do the trick, maybe similar to html.dark, ie. html[dir="rtl"] to provide optional direction. I'll check browser support and test.
https://caniuse.com/css-dir-pseudo
https://caniuse.com/?search=direction

@shadeed has a great guide about RTL styling here: https://rtlstyling.com/posts/rtl-styling

Thank you.

[gigamaster]

I'll merge the fix ToolsPane and update.
Thanks for the prompt reply and @shadeed guide, it's really helpful ^_^/

[gigamaster]

I'll merge the fix ToolsPane and update. Thanks for the prompt reply and @shadeed guide, it's really helpful ^_^/

UI darkmode
add menus project, settings, help
remove CodeRunButton
mobile orientation landscape
assets base64 scroll

[hatemhosny]

Thank you @gigamaster
I had a look around

UI darkmode
add menus project, settings, help

Yes, I see now what you mean. I think this is a nice layout. That's more organized.
We can continue this pathway.

The hint tooltip covers the first menu item. It needs to be moved.
May be change class="menu hint--bottom" to class="menu hint--right"

remove CodeRunButton
mobile orientation landscape

This was needed for small screens because of lack of space in the top bar. I see you have not yet implemented the design for mobile portrait orientation. So, I'll just wait to see how this evolves. We also have now the login button (which is no longer in menu).

assets base64 scroll

I'm not sure this is useful. It might even be a bit confusing for users to scroll through the very long data urls.
I cannot find a delete button for assets. Unrecognized file icon (e.g. csv) does not have enough contrast to background.

The embedded playgrounds now break (demo).
In embedded playgrounds I move the logo to the right and use it to open the current project in the full standalone app.
The selector is no longer able to find the element to it crashes. You can find selectors here. You probably need to preserve these or replace them with valid selectors.

The dark loading screen should work only in dark mode. At that time the app data have not been loaded yet.
We faced this issue while implementing translation for the loading text. The code for i18n feature provides a solution for that which we can use for this once the other is merged.

Please go on. I like the direction you are going.
Thank you.

[gigamaster]

Thank you @gigamaster I had a look around

UI darkmode
add menus project, settings, help

Yes, I see now what you mean. I think this is a nice layout. That's more organized. We can continue this pathway.

The hint tooltip covers the first menu item. It needs to be moved. May be change class="menu hint--bottom" to class="menu hint--right"

remove CodeRunButton
mobile orientation landscape

This was needed for small screens because of lack of space in the top bar. I see you have not yet implemented the design for mobile portrait orientation. So, I'll just wait to see how this evolves. We also have now the login button (which is no longer in menu).

assets base64 scroll

I'm not sure this is useful. It might even be a bit confusing for users to scroll through the very long data urls. I cannot find a delete button for assets. Unrecognized file icon (e.g. csv) does not have enough contrast to background.

The embedded playgrounds now break (demo). In embedded playgrounds I move the logo to the right and use it to open the current project in the full standalone app. The selector is no longer able to find the element to it crashes. You can find selectors here. You probably need to preserve these or replace them with valid selectors.

The dark loading screen should work only in dark mode. At that time the app data have not been loaded yet. We faced this issue while implementing translation for the loading text. The code for i18n feature provides a solution for that which we can use for this once the other is merged.

Please go on. I like the direction you are going. Thank you.

Hi @hatemhosny

The main idea is to make the user interface layout match the modern web apps design that Internet users are familiar with.
If visuals are important, we remember more about how a web app helped to achieve our goals, and how easy it was to do it. Let's say you are on the go, on a train or plane, and want to elaborate an idea, the choice would be pencil and paper or "livecodes". The goal is then to maximize the area of code and minimize the menus to provide quick access to features (spacing items to later customize with icons and keyboard shortcuts). I thought a tools menu could be useful to move the asset manager, code snippets and allow other add-ons, e.g. CSS color and unit conversion, cloud storage (link, modal or popup), more on this later.

The base64 asset scrolling was an attempt to fix the very long string after adding an image. While I try to avoid touching the core files as much as possible, I noticed that modals have a different HTML element structure that can't be solved by CSS alone, same for tabindex and flex ordering to facilitate LTR and RTL.

Some buttons don't show up, but I find them useful, for example, split and full screen.
Are they supposed to be used only on the embedded playground?

Thanks for reporting the issues - I'll check that out further.
Have fun ^_^/

[gigamaster]

• Todo nav - menu

ConsistencyNot conventional
Use hr instead of the separator role to ensure accessibility across all devices.

Validation Error: Element hr not allowed as child of element ul
HR shouldn't be recommended since it's invalid.

However, the li[role="separator"] is allowed in HTML 5.2
Ref.:
https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-editor/
https://www.w3.org/TR/html52/grouping-content.html#the-li-element

Issue:
whatwg/html#9247

listitem role (default - do not set), option, presentation, radio, separator, tab or treeitem.

[hatemhosny]

The main idea is to make the user interface layout match the modern web apps design that Internet users are familiar with.
If visuals are important, we remember more about how a web app helped to achieve our goals, and how easy it was to do it. Let's say you are on the go, on a train or plane, and want to elaborate an idea, the choice would be pencil and paper or "livecodes". The goal is then to maximize the area of code and minimize the menus to provide quick access to features (spacing items to later customize with icons and keyboard shortcuts). I thought a tools menu could be useful to move the asset manager, code snippets and allow other add-ons, e.g. CSS color and unit conversion, cloud storage (link, modal or popup), more on this later.

I do agree on the concept and approach. I think this is indeed more organized.

The base64 asset scrolling was an attempt to fix the very long string after adding an image. While I try to avoid touching the core files as much as possible, I noticed that modals have a different HTML element structure that can't be solved by CSS alone, same for tabindex and flex ordering to facilitate LTR and RTL.

I do not mind introducing some changes in HTML, so long that they do not break the app.
I just mean that showing the full data url is not useful to the user and may be confusing. No body would actually need to read the full data URL in contrast to other regular URLs which might be useful (e.g. when uploaded to github pages)
Another way of doing this would be to trim the URL so that it spans only 1 line, like the current implementation.
I also tried to make it look similar to the project list screen (Open ...), for familiarity and consistency.

The embedded playgrounds now break (demo).

It now works. Thank you.

Some buttons don't show up, but I find them useful, for example, split and full screen.
Are they supposed to be used only on the embedded playground?

Yes. Embedded playgrounds have limited space (inside the embedding page). So it would be useful to see the playground in full screen to have more room without taking up more space from the embedding page. In contrast, the full app already takes the full view port and can be easily viewed in full screen by pressing F11 (which is not available for embeds).
Same goes for the split toggle button. It is easier to manually resize in the full app.

On the other hand, all menus and login button should not be shown in embeds. I do not even attach event handlers to them.
It should be focused on just showing the UI necessary to edit some code and see the result. In case the user wants to do more, he can click on the logo (with the hint: edit in LiveCodes), which would take him to the full app with his project loaded.

This is the current view for embeds. We should hide all menus and the login button:

I noticed that changing the editor causes some flacky movement in the editor toolbar below:

Screenity.video.-.Sep.7.2024.mp4

However, the li[role="separator"] is allowed in HTML 5.2

I do like the menu separators. They make things a lot more organized and also look great.
Thank you.

[hatemhosny]

One more thing. The tooltip in the lowest menu item tries to appear below but overflows to the next column.
Maybe we should change all tooltips to appear on the right class="hint--right", like you did with the menu labels.
Also for changing language.

[gigamaster]

• App Menu ( spacing + flex)
• App Menu tooltip (language-item hint left position)
• Embed playground (remove menus + login)
• Console tests (result, fail css var)
• Console luna count (text color)
• Fixed editor toolbar (position absolute)
• Reverse asset manager + add action delete
• Removed .gitattributes (CRLF/LF)

WIP

• Dark & Light mode color scheme
• CSS vars
• LTR - RTL
  • Extra margin in flexbox - Browser bug ??
  • Menu select-editor
  • Position absolute (left-right)
• i18n
• Tests

[gigamaster]

Thank you @gigamaster

Here are some comments about issues I noticed:

The welcome and about screen share the same 2 column layout on desktop and 1 column on mobile.

In mobile, the welcome screen shows the recover section low down (off the view port) below the starter templates. It needs to be on the top.

Hmm... this relates to mode landscape taking over portrait... the other issues are related to console and tagify styles.
I will check how to override these CSS Properties.

The layout is handled by the layout configuration setting, which is responsive by default. This is not what I meant. I meant that in mobile in portrait orientation some elements are no longer shown:

I see what you mean. Maybe this can be added as an optional toggle (something like: "show grid"). Nice idea. I'm intrested to know about the students using LiveCodes :)

Just observe how people hold their phones in different ways at different times - in portrait mode when reading, or passively addicted to infinite scrolling, and in landscape mode when gaming, watching videos, working creatively and productively.

^_^/

[hatemhosny]

Since we all have different eyes, Livecodes can now enable customization and color experience: Hue-, s-, l-, and maybe font-size.

Regarding font-size, there is a fontSize config setting which controls the editor font size. The UI font size can either be the same or based on it, which makes sense.

In welcome screen, in light mode, on hover, the links are not distinguishable from background

In light mode, I think we need to make the switch in "off" state a bit dimmed to be distinguishable from "on" state.

Can we make the logo slightly bigger? It looks a bit too small.
The current width is 24px. Maybe if we make it 32px it will be more obvious without affecting the space around it. What do you think?

[hatemhosny]

Just observe how people hold their phones in different ways at different times - in portrait mode when reading, or passively addicted to infinite scrolling, and in landscape mode when gaming, watching videos, working creatively and productively.

I agree. Most of the time on mobile, it will be in landscape orientation. However, the app should still be usable in portrait even if we do not show the less important elements.

[hatemhosny]

hey @gigamaster

I like the portrait mode :)
The 2-rows idea at the top is clever.
The modals (and tabs) and the menus/submenus look very nice in portrait 👍
Thank you.

Here are some more comments: 😅

When in embed:

• in portrait, we need to keep it as a 1 row and place the icons at the end of that row
• 1 or 2 editor tabs can only be visible using the languages config (e.g. ?languages=css,js or ?languages=js). In that case, the editor title button is small (specially when showing only 1 button)
• the tooltip for the fullscreen button is not shown properly

The welcome screen links now are good in light mode. Thank you.
I noticed that the link for "click for info" for Default template takes too much space. And The "Default template" label spans 2 rows.

We need to update the focus mode to hide the buttons for project, settings and help menus.

When closing console in dark mode, the console background flashes in white color while closing.

closing-console.mp4

The social icons in the share screen are dark

The test editor is small and takes a small part of the screen

by the way, the test results look beautiful in light and dark modes. Very pretty :)

At last, I have some good and bad news:
The good news is that we have at last merged the i18n feature by @zyf722 . I'm very excited about that.
The bad news is that we have some new merge conflicts now :) I hope they are not too difficult to fix.

Thank you very much and sorry for overloading 💚

[gigamaster]

Hi @hatemhosny

The CSS comments were left in styles e.g. //TODO test embed, simple, etc. while waiting to have some examples of use.
I haven't touched the tests and shared icons, which can be moved to the icons.css or try to add a style in each icon, however I'm not sure if using the img tag will allow a change from dark to light.
Also noticed that after removing the body background, the Monaco editor shows a vertical white line depending on the resolution or when resizing the result. Maybe Monaco, or Luna Console or Tooltip, who knows, what causes the flickering, the blue line appearing randomly and the z-index conflicts, let's check this abnormal behavior 🔍

[hatemhosny]

I haven't touched the tests and shared icons, which can be moved to the icons.css or try to add a style in each icon, however I'm not sure if using the img tag will allow a change from dark to light.

The color of the share icon images can be changed by using filter

#modal #share-screen li img {
  filter: invert(1);
}

/* in dark mode */
#modal #share-screen li img {
  filter: invert(0.8);
}

Maybe Monaco, or Luna Console or Tooltip, who knows, what causes the flickering

To prevent the flickering in dark mode we can do a workaround like this:

/* in dark mode */
#output {
   background-color: #242424;
}
#result {
  background-color: #fff;
}

not pretty but works!

[gigamaster]

• added data-hint full screen and fixed tooltip

• added text-overflow: ellipsis to select-editor
  so the programming language will not hide the language menu

• added text-overflow: ellipsis to project-title,
  prevent long title from wrapping (unreadable in portrait mode)

• changed embed portrait mode to flex: nowrap

• changed welcome "Default template" label

• removed old style half-width ( fixed editor title button)

• reverted background changes for html.dark

• updated focus mode to hide menus: project, settings and help

• custom editor height

• links contrast

• modal prompt

• style the share icons
  (I would like to try different colors with the UI)

Notes

1. The white border and border radius issue on dark mode :

const createIframe
if (containerElement.dataset.defaultStyles !== 'false' && !headless), 133
/livecodes/src/sdk/index.ts

2. Loading index (css background white)
   Could use CSS media feature prefers-color-scheme

3. @zyf722 i18n has been merged to dev-gui
   conflicts are in console and dark mode notifications from your pr to dev-gui,
   editor-tools span changed for tag button, and SVG icons to CSS,
   the about html (translation to update) and toolbar menus (project, settings, help) which might also be missing translation.

[sonarcloud]

Quality Gate failed

Failed conditions
2 Security Hotspots

See analysis details on SonarCloud

[hatemhosny]

Hi @gigamaster

• I noticed the Welcome screen now displays "Recover" at the top. I think the order needs adjustment:

In 2-column layout:

Start	Recover (+/-)
Recent	About LiveCodes
Starter Templates

In 1-column layout:

Recover (+/-)
Start
Recent
Starter Templates
About LiveCodes

• In the Recover section, the cancel button stopped working.

[hatemhosny]

• It seems that the resize label (that displays the page dimensions) is no longer displayed. (edit: this is sometimes shown or hidden)
• The background of the result page should be white even in dark mode.

[gigamaster]

Hi @hatemhosny

Livecodes actually displays the "Recover" at the bottom; on request, the PR changed the modal to display "Recover" at the top on desktop and mobile, however the flex order can be set differently for LTR - RTL.
In the Recover section, the cancel button has not stopped working, but the UI file style "max-height: 0px;" has no effect on the layout space allocated to "Recover".

• It seems that the resize label (that displays the page dimensions) is no longer displayed. (edit: this is sometimes shown or hidden)

Unable to reproduce this, as the request was only to change the CSS color contrast.

• The background of the result page should be white even in dark mode.

This can be forced in html.dark { background }

You might want to check the translation :

• header menus are not translated
• innerHTML translation of login/logout removes the icon
• deploy dialog/modal is not translated.
• in the "Edit Tests" modal there is a pending task

TODO: add a link to the docs
See the docs for more details

[hatemhosny]

Thank you @gigamaster

Livecodes actually displays the "Recover" at the bottom; on request, the PR changed the modal to display "Recover" at the top on desktop and mobile, however the flex order can be set differently for LTR - RTL.

On small screens, I changed the order to put it on top.

In the Recover section, the cancel button has not stopped working, but the UI file style "max-height: 0px;" has no effect on the layout space allocated to "Recover".

I see. This is probably because it now has a display: inline.
Should we change this to welcomeRecover.style.display = 'block'; ?

Also shall we animate it?

cancel-recover.mp4

• It seems that the resize label (that displays the page dimensions) is no longer displayed. (edit: this is sometimes shown or hidden)

Unable to reproduce this, as the request was only to change the CSS color contrast.

I mean like this:

resize-label.mp4

• The background of the result page should be white even in dark mode.

This can be forced in html.dark { background }

Do you mean this code should be added by users in the editor?
The result page background should default to white color without having to style it.

You might want to check the translation :

• header menus are not translated
• innerHTML translation of login/logout removes the icon
• deploy dialog/modal is not translated.
• in the "Edit Tests" modal there is a pending task

I believe @zyf722 is busy these days.
Probably when he is back, he can help with this.

[hatemhosny]

by the way, please check this :)

Do you have any suggestions for styles?
It still needs to be translated.

[gigamaster]

by the way, please check this :)

Do you have any suggestions for styles? It still needs to be translated.

It's informative and looks nice. I will merge dev with the latest css changes in dev-gui. Aside from accent HUE input range for local storage and review i18n translations, without touching the core and adding an extra layer of complexity, it's pretty much done for the UI/UX.

I'd recommend merging it with the dev branch, and maybe most importantly, consider highlighting the dev branch.
This helps to better understand the progress of the project, facilitate feedback on usability (UX) and future improvements - UI, i18n, etc.

A very opiniated direction would be to recommend focusing on user needs, instead of the Tower of Babel Confusio Linguarum. Mainly because VS Code was never built for mobile phones, and only recently has Apple reversed its decision about blocking web apps (PWAs) on iPhones in the EU. Replit has focused its campaign on this very specific need, drawing attention to mobility. Unfortunately, their “visual material” goes wrong when it comes to “showing” everyday use, which leads to a sort of cognitive dissonance in their main message. Connection to a remote machine, like a bare metal or virtual machine, via a secure tunnel, remote development environments, or generally speaking, cloud services turn to be heavy and slow.

Recently, I noticed that sources were not being found when using mobile applications. Taking a closer look at network performance, just to find out that using the CDN comes with its own set of challenges. Among the common problems that can occur, we saw latencies, cache misses and content delivery failures, resulting in data loss, data blocking, data inaccuracies, user inefficiency, bandwidth reduction and slowdowns, to name but a few.

Livecodes could therefore meet the need for a portable application, lightning-fast and responsive, focused on individuals and their mobility needs. Not only because it's a niche, but also because it's where the tech giants fall that individuals can rise.
^_^/

[gigamaster]

Quick look codespace vs livecodes