ਟਾਈਪਰਾਈਟਰ ਪ੍ਰਭਾਵ ਕਿਸੇ ਨੂੰ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਸੋਚਦੇ ਹੋਏ ਦੇਖਣ ਦਾ ਡਿਜੀਟਲ ਬਰਾਬਰ ਹੈ। ਟੈਕਸਟ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਅੱਖਰ ਵਜੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਕੋਈ ਅਸਲੀ ਹੱਥ ਅਸਲੀ ਕੀਜ਼ (keys) ਦਬਾ ਰਿਹਾ ਹੋਵੇ। ਤੁਸੀਂ ਇਸਨੂੰ ਪੋਰਟਫੋਲੀਓ ਸਾਈਟਾਂ ਦੇ ਹੀਰੋ ਸੈਕਸ਼ਨਾਂ ਵਿੱਚ, ਬ੍ਰਾਊਜ਼ਰ-ਅਧਾਰਤ ਟਰਮੀਨਲ ਇਮੂਲੇਟਰਾਂ ਵਿੱਚ, ਅਤੇ AI ਸਹਾਇਕਾਂ ਦੀਆਂ ਚੈਟ ਵਿੰਡੋਜ਼ ਵਿੱਚ ਦੇਖਦੇ ਹੋ ਜੋ ਇਹ ਸਾਬਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਉਹ ਕੋਈ ਪਹਿਲਾਂ ਤੋਂ ਤਿਆਰ ਟੈਕਸਟ ਲਿਆਉਣ ਦੀ ਬਜਾਏ ਜਵਾਬ "ਟਾਈਪ" ਕਰ ਰਹੇ ਹਨ। ਜਦੋਂ ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਉਤਸੁਕਤਾ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਮਾੜੇ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ 1987 ਵਿੱਚ ਫਸੇ ਹੋਏ ਪ੍ਰਿੰਟਰ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ।

ਇਹ ਪੈਟਰਨ ਕਿਉਂ ਬਣਿਆ ਰਹਿੰਦਾ ਹੈ

ਕੰਪਿਊਟਰ ਜਾਣਕਾਰੀ ਤੁਰੰਤ ਦਿੰਦੇ ਹਨ। ਇਨਸਾਨ ਨਹੀਂ। ਉਹਨਾਂ ਦੋਵਾਂ ਦੀਆਂ ਗਤੀਆਂ ਵਿਚਕਾਰ ਦਾ ਅੰਤਰ ਲਾਭਦਾਇਕ ਹੈ। ਟਾਈਪਰਾਈਟਰ ਪ੍ਰਭਾਵ ਮਨੁੱਖੀ ਗਤੀ ਦੀ ਨਕਲ ਕਰਕੇ ਇਸ ਅੰਤਰ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਇੱਕ ਲੈਂਡਿੰਗ ਪੇਜ 'ਤੇ, ਇਹ ਇੱਕ ਹੈੱਡਲਾਈਨ ਨੂੰ ਸ਼ਬਦ-ਦਰ-ਸ਼ਬਦ ਅੱਖਾਂ ਦੇ ਸਾਹਮਣੇ ਲਿਆ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਵਿਜ਼ਿਟਰ ਸਿਰਫ਼ ਉੱਪਰ-ਉੱਪਰੋਂ ਦੇਖਣ ਦੀ ਬਜਾਏ ਅਸਲ ਮੁੱਲ ਪ੍ਰਸਤਾਵ (value proposition) ਨੂੰ ਪੜ੍ਹਨ। ਇੱਕ ਟਰਮੀਨਲ ਇਮੂਲੇਟਰ ਵਿੱਚ, ਇਹ ਇਹ ਭਰਮ ਪੈਦਾ ਕਰਦਾ ਹੈ ਕਿ ਕਮਾਂਡਾਂ ਰੀਅਲ-ਟਾਈਮ ਵਿੱਚ ਚੱਲ ਰਹੀਆਂ ਹਨ। ਇੱਕ ਚੈਟਬੋਟ ਇੰਟਰਫੇਸ ਵਿੱਚ, ਇਹ ਲੈਅ (rhythm) ਇਹ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ ਕਿ ਜਵਾਬ ਡਾਟਾਬੇਸ ਤੋਂ ਲਿਆਉਣ ਦੀ ਬਜਾਏ ਤੁਰੰਤ ਤਿਆਰ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

ਪਰ ਇਹ ਪ੍ਰਭਾਵ ਉਦੋਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇਕਰ ਇਸਦੀ ਮਕੈਨਿਕਸ ਯੂਜ਼ਰ ਦਾ ਸਤਿਕਾਰ ਕਰੇ। ਇੱਕੋ ਜਿਹੇ ਸਮੇਂ ਦੇ ਅੰਤਰਾਂ ਦੀ ਇੱਕ ਸਿੱਧੀ, ਮੈਟਰੋਨੋਮਿਕ (metronomic) ਟਿਕ-ਟਿਕ-ਟਿਕ ਰੋਬੋਟਿਕ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ, ਇੱਕ ਅਜਿਹਾ ਲਾਗੂਕਰਨ ਜੋ ਸਹਾਇਕ ਤਕਨਾਲੋਜੀ (assistive technology) ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ, ਇੱਕ ਮਜ਼ੇਦਾਰ ਵਿਜ਼ੂਅਲ ਸਜਾਵਟ ਨੂੰ ਇੱਕ ਨਿਰਾਸ਼ਾਜਨਕ ਰੁਕਾਵਟ ਵਿੱਚ ਬਦਲ ਸਕਦਾ ਹੈ। ਉਦੇਸ਼ ਯੂਜ਼ਰ ਨੂੰ ਹੌਲੀ ਕਰਨਾ ਨਹੀਂ ਹੈ; ਇਹ ਇੰਨਾ ਰਗੜ (friction) ਪੈਦਾ ਕਰਨਾ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਜਿਉਂਦਾ ਮਹਿਸੂਸ ਹੋਵੇ।

ਇਸਨੂੰ Recursive setTimeout ਨਾਲ ਬਣਾਓ

setTimeout ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ setInterval ਨੂੰ ਹੱਥ ਨਾ ਲਗਾਓ। ਇਸਦਾ ਅੰਤਰ ਉਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿੰਨਾ ਇਹ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।

setInterval ਜ਼ਿੱਦੀ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਸਕ੍ਰਿਪਟ ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਮੇਨ ਥ੍ਰੈਡ ਵਿੱਚ ਕੁਝ ਵੀ ਹੋ ਰਿਹਾ ਹੋਵੇ, ਭਾਵੇਂ ਕੁਝ ਵੀ ਹੋਵੇ, ਹਰ n ਮਿਲੀਸੈਕੰਡ ਬਾਅਦ ਚੱਲਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੇ ਲੌਜਿਕ ਨੂੰ ਆਮ ਕੀਸਟ੍ਰੋਕਸ ਦੇ ਵਿਚਕਾਰ 50-ਮਿਲੀਸੈਕੰਡ ਦਾ ਵਿਰਾਮ ਅਤੇ ਵਿਰਾਮ ਚਿੰਨ੍ਹਾਂ (punctuation) ਤੋਂ ਬਾਅਦ 150-ਮਿਲੀਸੈਕੰਡ ਦਾ ਵਿਰਾਮ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ setInterval ਅਨੁਕੂਲ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਤੁਸੀਂ ਇਸਨੂੰ ਵਾਧੂ ਕੰਡੀਸ਼ਨਲ ਲੌਜਿਕ ਵਿੱਚ ਲਪੇਟਣ, ਰੇਸ ਕੰਡੀਸ਼ਨਾਂ (race conditions) ਨਾਲ ਲੜਨ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਇੰਨੀ ਵਾਰ ਇੰਟਰਵਲ ਨੂੰ ਕਲੀਅਰ ਅਤੇ ਰੀਸੈੱਟ ਕਰਨ ਲਈ ਮਜਬੂਰ ਹੋ ਜਾਂਦੇ ਹੋ ਕਿ ਕੋਡ ਇੱਕ ਸਟੇਟ-ਮੈਨੇਜਮੈਂਟ ਕੋਸ਼ (state-management nightmare) ਬਣ ਜਾਂਦਾ ਹੈ। ਫਿਕਸਡ ਇੰਟਰਵਲ ਉਸ ਸਮੇਂ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਤੁਹਾਨੂੰ ਵਧਦੇ-ਘਟਦੇ ਸਪੀਡ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਰਿਕਰਸਿਵ setTimeout ਇਸਨੂੰ ਹਰ ਕਦਮ ਨੂੰ ਅਗਲੇ ਕਦਮ ਲਈ ਨਿਯਮ ਤੈਅ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਕੇ ਠੀਕ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਛੋਟੀ ਸਟੇਟ ਮਸ਼ੀਨ ਵਜੋਂ ਸਮਝੋ। ਤੁਸੀਂ ਕੁਝ ਵੇਰੀਏਬਲ ਰੱਖਦੇ ਹੋ: ਮੌਜੂਦਾ ਸਟ੍ਰਿੰਗ, ਮੌਜੂਦਾ ਅੱਖਰ ਇੰਡੈਕਸ, ਇੱਕ ਬੂਲੀਅਨ ਫਲੈਗ ਕਿ ਤੁਸੀਂ ਟਾਈਪ ਕਰ ਰਹੇ ਹੋ ਜਾਂ ਡਿਲੀਟ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਇੱਕ textIndex ਕਾਊਂਟਰ ਤਾਂ ਜੋ ਤੁਸੀਂ ਕਈ ਸਟ੍ਰਿੰਗਾਂ ਰਾਹੀਂ ਲੂਪ ਕਰ ਸਕੋ। ਫੰਕਸ਼ਨ ਇੱਕ ਅੱਖਰ ਜੋੜਦਾ ਹੈ, ਚੈੱਕ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਵਾਕ ਵਿੱਚ ਕਿੱਥੇ ਹੈ, ਫਿਰ ਆਪਣੇ ਅਗਲੇ ਕਾਲ (invocation) ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਡਿਲੇ ਨਾਲ ਸ਼ਡਿਊਲ ਕਰਦਾ ਹੈ ਜੋ ਸੰਦਰਭ (context) ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ।

ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਜ਼ਿਆਦਾਤਰ ਅੱਖਰਾਂ ਨੂੰ 50 ਮਿਲੀਸੈਕੰਡ 'ਤੇ ਟਾਈਪ ਕਰ ਸਕਦੇ ਹੋ, ਕਾਮੇ ਤੋਂ ਬਾਅਦ 150 ਮਿਲੀਸੈਕੰਡ ਤੱਕ ਹੌਲੀ ਹੋ ਸਕਦੇ ਹੋ, ਅਤੇ ਡਿਲੀਟ ਮੋਡ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਪੂਰੇ ਵਾਕ ਦੇ ਅੰਤ ਵਿੱਚ 800 ਮਿਲੀਸੈਕੰਡ ਲਈ ਰੁਕ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ setInterval ਨਾਲ ਇਹ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਰਿਕਰਸਿਵ setTimeout ਦੇ ਨਾਲ, ਲੌਜਿਕ ਸਪੱਸ਼ਟ ਹੈ:

if typing:
  append next character
  if at end of string:
    switch to pause mode
    schedule next call after 1000ms
if deleting:
  remove last character
  if string empty:
    increment textIndex
    load next string
    switch to typing mode

ਇਹ ਢਾਂਚਾ ਸਫਾਈ (cleanup) ਨੂੰ ਵੀ ਬਹੁਤ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ। ਟਾਈਮਆਊਟ ID ਨੂੰ ਸਟੋਰ ਕਰੋ। ਜਦੋਂ ਕੰਪੋਨੈਂਟ ਅਨਮਾਊਂਟ (unmount) ਹੁੰਦਾ ਹੈ ਜਾਂ ਯੂਜ਼ਰ ਦੂਜੇ ਪੇਜ 'ਤੇ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਵਾਰ clearTimeout ਨੂੰ ਕਾਲ ਕਰੋ। ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਚੱਲਦੇ ਹੋਏ ਕੋਈ ਵੀ ਅਣਵਰਤੇ ਇੰਟਰਵਲ ਨਹੀਂ ਰਹਿਣਗੇ।

ਬਲਿੰਕਿੰਗ ਕਰਸਰ ਇੱਕ ਵਿਜ਼ੂਅਲ ਡਿਟੇਲ ਹੈ, ਡਾਟਾ ਦੀ ਚਿੰਤਾ ਨਹੀਂ। ਇਸਨੂੰ ਆਪਣੇ JavaScript ਸਟੇਟ ਇੰਜਣ ਤੋਂ ਦੂਰ ਰੱਖੋ। ਇੱਕ ਵੱਖਰਾ CSS ਐਨੀਮੇਸ਼ਨ ਵਰਤੋ ਜੋ ::after ਸਊਡੋ-ਐਲੀਮੈਂਟ ਜਾਂ ਤੁਹਾਡੇ ਟੈਕਸਟ ਕੰਟੇਨਰ ਦੇ ਅੰਤ ਵਿੱਚ ਬੈਠੇ ਇੱਕ ਸਮਰਪਿਤ <span ਨਾਲ ਜੁੜਿਆ ਹੋਵੇ।

ਇੱਕ ਸਧਾਰਨ @keyframes blink ਜੋ step-end ਟਾਈਮਿੰਗ ਦੇ ਨਾਲ opacity ਜਾਂ border-color ਨੂੰ ਬਦਲਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਫ਼, ਹਾਰਡਵੇਅਰ-ਅਨੁਕੂਲ ਪਲਸ ਦਿੰਦਾ ਹੈ ਜੋ ਕੰਪੋਜ਼ਿਟਰ 'ਤੇ ਚੱਲਦਾ ਹੈ। JavaScript ਦਾ ਕਰਸਰ ਦੀ ਦਿੱਖ ਨੂੰ ਮਾਈਕਰੋ-ਮੈਨੇਜ ਕਰਨ ਦਾ ਕੋਈ ਕੰਮ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਆਪਣੇ setTimeout ਰਿਕਰਸ਼ਨ ਦੇ ਅੰਦਰੋਂ ਡਿਸਪਲੇਅ ਪ੍ਰੋਪਰਟੀਜ਼ ਨੂੰ ਟੌਗਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਹਰ ਇੱਕ ਅੱਖਰ 'ਤੇ ਬੇਲੋੜੇ ਸਟਾਈਲ ਰੀਕੈਲਕੂਲੇਸ਼ਨ (style recalculations) ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹੋ। ਸੁੰਦਰਤਾ (aesthetics) ਨੂੰ CSS ਨੂੰ ਸੰਭਾਲਣ ਦਿਓ। ਕ੍ਰਮ (sequence) ਨੂੰ JavaScript ਨੂੰ ਸੰਭਾਲਣ ਦਿਓ।

textIndex ਕਾਊਂਟਰ ਦੇ ਨਾਲ ਕਈ ਸਟ੍ਰਿੰਗਾਂ ਰਾਹੀਂ ਲੂਪ ਕਰਨਾ ਸਿੱਧਾ ਹੈ। ਆਪਣੀਆਂ ਸਟ੍ਰਿੰਗਾਂ ਨੂੰ ਇੱਕ ਐਰੇ (array) ਵਿੱਚ ਸਟੋਰ ਕਰੋ। ਜਦੋਂ ਐਨੀਮੇਸ਼ਨ ਆਪਣਾ ਡਿਲੀਟ ਫੇਜ਼ ਖਤਮ ਕਰਦੀ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਖਾਲੀ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਐਰੇ ਦੀ ਲੰਬਾਈ ਦੇ ਮੋਡੂਲੋ (modulo) textIndex ਨੂੰ ਵਧਾਓ, ਅੱਖਰ ਪੁਆਇੰਟਰ ਨੂੰ ਜ਼ੀਰੋ 'ਤੇ ਰੀਸੈੱਟ ਕਰੋ, ਅਤੇ ਦੁਬਾਰਾ ਟਾਈਪ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ। ਇਸ ਤਰ੍ਹਾਂ

setInterval ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਵੈਰੀਏਬਲ-ਸਪੀਡ (variable-speed) ਸਮੱਸਿਆ ਬਾਰੇ ਗੱਲ ਕਰ ਚੁੱਕੇ ਹਾਂ, ਪਰ ਇੱਕ ਹੋਰ ਬਾਰੀਕ ਮੁੱਦਾ ਵੀ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ DOM ਅੱਪਡੇਟ ਕਦੇ ਲੈਗ (lag) ਕਰਦਾ ਹੈ—ਮੰਨ ਲਓ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਲੇਆਉਟ ਸ਼ਿਫਟ (layout shift) ਪੇਂਟ ਕਰ ਰਿਹਾ ਹੈ—ਤਾਂ setInterval ਲਗਾਤਾਰ ਚਲਦਾ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਨਾਲ ਲਿਖਣ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕ ਦੂਜੇ ਦੇ ਉੱਪਰ ਆ ਸਕਦੀਆਂ ਹਨ, ਡੁਪਲੀਕੇਟ ਅੱਖਰ ਬਣ ਸਕਦੇ ਹਨ, ਜਾਂ ਲਿਖਣ ਦੀ ਗਤੀ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਰੈਂਡਰ (render) ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਤੋਂ ਤੇਜ਼ ਹੋ ਸਕਦੀ ਹੈ। ਰਿਕਰਸਿਵ (Recursive) setTimeout ਅਗਲੇ ਕਦਮ ਬਾਰੇ ਸੋਚਣ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਕਦਮ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ।

HTML ਨੂੰ ਐਸਕੇਪ (escape) ਕਰਨਾ ਭੁੱਲ ਜਾਣਾ। ਜੇਕਰ ਤੁਹਾਡੀਆਂ ਸੋਰਸ ਸਟ੍ਰਿੰਗਾਂ (source strings) ਵਿੱਚ ਐਂਗਲ ਬ੍ਰੈਕਟਸ (angle brackets) ਹਨ, ਅਤੇ ਤੁਸੀਂ innerHTML ਰਾਹੀਂ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਅੱਖਰ ਇੰਜੈਕਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਟੈਗਸ ਨੂੰ ਅੱਧੇ ਵਿੱਚ ਹੀ ਵੰਡ ਦਿਓਗੇ। ਬ੍ਰਾਊਜ਼ਰ ਪਹਿਲਾਂ <, ਫਿਰ <s, ਅਤੇ ਫਿਰ <st ਦੇਖਦਾ ਹੈ। ਇਹ ਸਹੀ ਟੈਗ ਪਾਰਸਿੰਗ (tag parsing) ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਟੁੱਟੇ ਹੋਏ DOM ਨੋਡਸ ਜਾਂ ਅਣਚਾਹੇ ਸਟਾਈਲਿੰਗ ਕੈਸਕੇਡ (styling cascades) ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਅਸਲੀ ਅੱਖਰ ਦਿਖਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਐਸਕੇਪ ਕਰੋ ਜਾਂ, ਹੋਰ ਵੀ ਵਧੀਆ ਹੈ ਕਿ innerHTML ਦੀ ਬਜਾਏ textContent ਵਿੱਚ ਲਿਖੋ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਟਾਈਪਰਾਈਟਰ ਆਉਟਪੁੱਟ ਦੇ ਅੰਦਰ ਸਟਾਈਲਡ ਸਪੈਨ (styled spans) ਦੀ ਸੱਚਮੁੱਚ ਲੋੜ ਹੈ, ਤਾਂ ਸਟ੍ਰਿੰਗ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰੋਸੈਸ (pre-process) ਕਰੋ ਤਾਂ ਜੋ ਅੱਖਰਾਂ ਦੇ ਲੂਪ (character loop) ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਟੈਗ ਕਿੱਥੇ ਸ਼ੁਰੂ ਅਤੇ ਖਤਮ ਹੁੰਦੇ ਹਨ।

ਐਕਸੈਸਬਿਲਟੀ (accessibility) ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ। ਸਕ੍ਰੀਨ ਰੀਡਰਾਂ (Screen readers) ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਅੱਖਰ ਪੜ੍ਹਨਾ ਪਸੰਦ ਨਹੀਂ ਹੁੰਦਾ। ਜਿਵੇਂ ਹੀ ਤੁਹਾਡਾ ਸਕ੍ਰਿਪਟ DOM ਵਿੱਚ ਹਰ ਨਵਾਂ ਅੱਖਰ ਜੋੜਦਾ ਹੈ, ਕੁਝ ਸਹਾਇਕ ਤਕਨੀਕਾਂ (assistive technologies) ਪੂਰੇ ਨੋਡ ਦੀ ਦੁਬਾਰਾ ਘੋਸ਼ਣਾ ਕਰਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਅਧੂਰੇ ਸ਼ਬਦਾਂ ਦੀ ਇੱਕ ਲਗਾਤਾਰ ਰੌਲਾ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਆਡੀਟਰੀ ਨੈਵੀਗੇਸ਼ਨ (auditory navigation) 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਲਈ ਇੱਕ ਦੁਸ਼ਵਾਰੀ ਹੈ। ਇਸਦਾ ਹੱਲ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹੈ: ਉਸ ਕੰਟੇਨਰ (container) ਵਿੱਚ ਇੱਕ aria-label ਜੋੜੋ ਜਿਸ ਵਿੱਚ ਪੂਰਾ ਅਤੇ ਅੰਤਿਮ ਟੈਕਸਟ ਹੋਵੇ। ਤੁਸੀਂ aria-hidden="true" ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਐਨੀਮੇਟਡ ਐਲੀਮੈਂਟ ਨੂੰ ਸਹਾਇਕ ਤਕਨੀਕਾਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੁਕਾ ਵੀ ਸਕਦੇ ਹੋ ਅਤੇ ਸਕ੍ਰੀਨ ਰੀਡਰਾਂ ਲਈ ਇੱਕ ਵਿਜ਼ੂਅਲੀ ਲੁਕਵੀਂ (visually hidden) ਸਟੈਟਿਕ ਕਾਪੀ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹੋ। ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ, ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਤੁਹਾਡੇ ਪਰਫਾਰਮੈਂਸ ਨੂੰ ਦੇਖਣ ਲਈ ਮਜਬੂਰ ਕਰਨ ਦੀ ਬਜਾਏ, ਉਹਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪੂਰਾ ਵਾਕ ਦਿਓ।

ਆਪਣੇ ਵਰਜ਼ਨ ਨੂੰ ਨਿਖਾਰਨ ਦੇ ਤਰੀਕੇ

ਇੱਕ ਵਾਰ ਜਦੋਂ ਕੋਰ ਲੂਪ (core loop) ਸਹੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਨ ਲੱਗ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ ਵਾਧੂ ਚੀਜ਼ਾਂ ਜੋੜ ਸਕਦੇ ਹੋ। ਪਰ ਜਦੋਂ ਤੱਕ ਬੁਨਿਆਦੀ ਤੱਤ ਮਜ਼ਬੂਤ ਨਹੀਂ ਹੋ ਜਾਂਦੇ, ਉਹਨਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਇੱਛਾ ਨੂੰ ਰੋਕੋ।

ਕੀਸਟ੍ਰੋਕ ਸਾਊਂਡ ਇਫੈਕਟਸ (Keystroke sound effects)। ਹਰ ਅੱਖਰ 'ਤੇ ਇੱਕ ਹਲਕੀ ਜਿਹੀ ਕਲਿੱਕ ਦੀ ਆਵਾਜ਼ ਸੰਤੁਸ਼ਟੀਜਨਕ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਵੈੱਬਪੇਜਾਂ 'ਤੇ ਆਡੀਓ ਇੱਕ ਖ਼ਤਰਨਾਕ ਮੈਦਾਨ ਵਾਂਗ ਹੈ। Web Audio API ਜਾਂ ਇੱਕ ਛੋਟੇ ਬਫਰ (buffer) ਵਾਲੇ ਹਲਕੇ Audio ਐਲੀਮੈਂਟ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਪਲੇਬੈਕ ਰੇਟ (playback rate) ਵਿੱਚ ਥੋੜ੍ਹਾ ਜਿਹਾ ਵਾਧਾ-ਘਾਟਾ ਕਰੋ—0.95 ਅਤੇ 1.05 ਦੇ ਵਿਚਕਾਰ—so ਕਿ ਇੱਕੋ ਜਿਹੇ ਕਲਿੱਕ ਸਿੰਥੈਟਿਕ (synthetic) ਨਾ ਲੱਗਣ। ਹਮੇਸ਼ਾ ਬ੍ਰਾਊਜ਼ਰ ਦੀਆਂ ਆ