Versions Compared

Old Version 11

changes.mady.by.user Danny Gibas

Saved on

compared with

New Version 12

changes.mady.by.user Danny Gibas

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

  1. Global vs On-page Indication bug

    Problem: Global vs On-page red indicators are not 100% accurate.
    Details: If the CSS Prop is being used in the <template> instead of the CSS, for example in a component prop <component color="--ads-component-color"> then testing for use on the page will not get picked up by the parser and the indicator will imply the prop is not used on the page even though it is. This makes the indicator unreliable and toggling global props off in the options menu may hide controls for props that are actually used on the page.

  2. Single app support per save file

    Problem: Theme designer can only currently support one application per save file, so each app currently requires its own save container on Azure.
    Details:When saving, the exposed props in the app overwrite the save file. This means any props exposed in other apps using the same save file would be overwritten and therefore each app requires its own safe file and setup at this time.

  3. Vuetify version conflicts

    Problem: Theme Designer uses a newer version of Vuetify then NOP and Sep-UI due to needed component offerings and this version conflict causes some CSS/Layout issues with Vuetify components in the store while Theme Designer is loaded. This has no impact on the live store other people see.
    Details: Theme designer uses Vuetify V3. Sep UI and NOP both use Vuetify 2. There are CSS differences between the two versions and they leak into eachother when TD is enabled. This causes some layout discrepancies in both the host app and in TD. Some have been resolved with using !important in the TD app, but some CSS issues remain unresolved unless/until Sep-ui and NOP is on Vuetify 3.

  4. Prop inconsistency in Theme Designer when Cloud header styles are activated

    Problem: The cloud header activation comes with some additional page styling for the PLP that hides a couple page styles that are assigned themable custom properties.
    Details: When a resort is on legacy but has the cloud header enabled, additional styles are inserted into the PLP that interfere with the ability of TD to fully style the page. These include editing the page background color and editing the card container drop shadow. This in itself is not the key issue, but rather that those props are still exposed in the NOP CSS and TD will generate the controls to adjust them but they will have no effect on the page. This is likely to cause confusion with TD users.

  5. Save file props are not adequately considered when scanning the CSS for exposed props

    Problem: When parsing all the page CSS imports, the JS builtin getPropertyValue() only evaluates prop values, not prop keys. So only the prop values referenced by prop keys get included. There is no equivalent getPropertyKey() built in method in JS to get property keys from a stylesheet.
    Details:
    For example:

    This is a save file prop. --ads-card-header-primary-color: red;
    Because --ads-card-header-primary-color is only referenced as the key, not the value (red), it would not be included in the prop list.

    In the same save file, we might have:
    --ads-card-header-primary-color: var(--ads-card-text-color)
    In this case, --var-card-text-color would get included in the site prop list because it is a value, but --ads-card-header-primary-color would still not get included, because it is a key.

    This may cause problems if we plan to use a single save file for multiple applications because this means we cannot rely on the save file to carry prop names over to another application unless those prop names are also used by some element in the host applications CSS. This may be a good or bad thing, depending on the use case.