ਇੱਕ ਨਵੀਂ CSS ਪ੍ਰੋਪਰਟੀ ਜਿਸਦਾ ਨਾਮ text-box-trim ਹੈ, ਉਹਨਾਂ ਬ੍ਰਾਊਜ਼ਰਾਂ ਵਿੱਚ ਆ ਗਈ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਜੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਲਾਈਨ-ਹਾਈਟ (line-height) ਦੀਆਂ ਉਹ ਮੁਸ਼ਕਲਾਂ ਖਤਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਜੋ ਸਾਲਾਂ ਤੋਂ UI ਕੰਮ ਦਾ ਇੱਕ ਮੁੱਖ ਹਿੱਸਾ ਰਹੀਆਂ ਹਨ। ਫੌਂਟ ਦੀ ਕੈਪ ਹਾਈਟ (cap height) ਦੇ ਉੱਪਰ ਅਤੇ ਬੇਸਲਾਈਨ (baseline) ਦੇ ਹੇਠਾਂ ਮੌਜੂਦ ਅਦਿੱਖ ਪੈਡਿੰਗ (padding) ਨੂੰ ਕੱਟ ਕੇ, ਇਹ ਪ੍ਰੋਪਰਟੀ ਵਰਟੀਕਲ ਟੈਕਸਟ ਅਲਾਈਨਮੈਂਟ (vertical text alignment) ਨੂੰ ਵਿਡਥ (width) ਜਾਂ ਰੰਗ (color) ਸੈੱਟ ਕਰਨ ਵਾਂਗ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।

ਇਹ ਸਮੱਸਿਆ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ

ਹਰ ਟਾਈਪਫੇਸ (typeface) ਵਿੱਚ "ਗੋਸਟ" (ghost) ਸਪੇਸ ਹੁੰਦੀ ਹੈ: ਸਭ ਤੋਂ ਵੱਡੇ ਕੈਪੀਟਲ ਅੱਖਰਾਂ ਦੇ ਉੱਪਰ ਕੁਝ ਪਿਕਸਲ ਅਤੇ ਉਸ ਲਾਈਨ ਦੇ ਹੇਠਾਂ ਕੁਝ ਪਿਕਸਲ ਜਿਸ 'ਤੇ ਅੱਖਰ ਟਿਕੇ ਹੁੰਦੇ ਹਨ। ਉਹ ਸਪੇਸ ਅਦਿੱਖ ਹੁੰਦੀ ਹੈ, ਪਰ ਇਹ ਬਟਨ ਦੇ ਲੇਬਲ ਨੂੰ ਉੱਪਰ ਜਾਂ ਹੇਠਾਂ ਧੱਕਦੀ ਹੈ, ਹੈਡਿੰਗ ਨੂੰ ਆਈਕਨ ਦੇ ਕਿਨਾਰੇ ਤੋਂ ਦੂਰ ਕਰ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਡਿਜ਼ਾਈਨਰਾਂ ਨੂੰ ਇਸਦੀ ਭਰਪਾਈ ਕਰਨ ਲਈ "ਮੈਜਿਕ ਨੰਬਰ" (magic numbers) ਜੋੜਨ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। ਟੀਮਾਂ ਨੇ ਉਹਨਾਂ ਐਡਜਸਟਮੈਂਟਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਪੂਰੇ ਸਪੇਸਿੰਗ ਸਿਸਟਮ—ਡਿਜ਼ਾਈਨ ਟੋਕਨ (design tokens), ਯੂਟੀਲਿਟੀ ਕਲਾਸਾਂ (utility classes), ਅਤੇ ਕੰਪੋਨੈਂਟ ਲਾਇਬ੍ਰੇਰੀਆਂ (component libraries)—ਬਣਾਏ ਹਨ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਪੈਡਿੰਗ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਹਟਾਉਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਦਿੰਦਾ ਸੀ।

ਪੁਰਾਣੇ ਤਰੀਕੇ (Workarounds)

text-box-trim ਤੋਂ ਪਹਿਲਾਂ, ਡਿਵੈਲਪਰ ਆਮ ਤੌਰ 'ਤੇ:

  • ਇੱਕ ਕਸਟਮ line-height ਦੀ ਗਣਨਾ ਕਰਦੇ ਸਨ ਜੋ ਵਾਧੂ ਸਪੇਸ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਸੀ।
  • ਟੈਕਸਟ ਨੂੰ ਉੱਪਰ ਜਾਂ ਹੇਠਾਂ ਖਿੱਚਣ ਲਈ ਨੈਗੇਟਿਵ ਮਾਰਜਿਨ (negative margins) ਲਗਾਉਂਦੇ ਸਨ।
  • ਡਿਜ਼ਾਈਨ ਫਾਈਲਾਂ ਤੋਂ ਨੰਬਰ ਕਾਪੀ ਕਰਦੇ ਸਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ CSS ਵਿੱਚ ਹਾਰਡ-ਕੋਡ ਕਰ ਦਿੰਦੇ ਸਨ।

ਉਹ ਤਰੀਕੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਪਰ ਉਹ ਕਮਜ਼ੋਰ ਹਨ। ਫੌਂਟ, ਵੇਟ (weight), ਜਾਂ ਭਾਸ਼ਾ ਬਦਲੋ, ਅਤੇ ਨੰਬਰ ਵਿਗੜ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਗਲਤ ਅਲਾਈਨਮੈਂਟ ਵਾਲੇ UI ਐਲੀਮੈਂਟਸ ਬਣਦੇ ਹਨ ਅਤੇ ਕੋਡਬੇਸ ਵਿੱਚ ਰੱਖ-ਰਖਾਅ ਦਾ ਬੋਝ ਵਧਦਾ ਹੈ।

text-box-trim ਖੇਡ ਨੂੰ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ

text-box-trim ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਟੈਕਸਟ ਬਾਕਸ ਨੂੰ ਅਸਲ ਗਲੀਫ ਬਾਊਂਡਜ਼ (glyph bounds) ਤੱਕ ਕਲਿੱਪ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਇਹ ਪ੍ਰੋਪਰਟੀ ਉਹਨਾਂ ਵੈਲਯੂਜ਼ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਜੋ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਕਿਹੜੇ ਕਿਨਾਰਿਆਂ ਨੂੰ ਟ੍ਰਿਮ ਕਰਨਾ ਹੈ, ਜਦੋਂ ਕਿ ਸਾਥੀ text-box-edge ਕੈਪ ਹਾਈਟ ਲਈ ਰੈਫਰੈਂਸ ਕਿਨਾਰਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ, ਇਹ ਸੈੱਟ ਕਰਨਾ:

button { text-box-trim: both; text-box-edge: cap; }

ਬਾਕਸ ਦੇ ਉੱਪਰਲੇ ਹਿੱਸੇ ਨੂੰ ਕੈਪ ਹਾਈਟ 'ਤੇ ਅਤੇ ਹੇਠਲੇ ਹਿੱਸੇ ਨੂੰ ਅਲਫਾਬੈਟਿਕ ਬੇਸਲਾਈਨ 'ਤੇ ਰੋਕ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਫੈਂਟਮ ਪੈਡਿੰਗ (phantom padding) ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਅਜਿਹੀ ਲਾਈਨ ਬਾਕਸ ਮਿਲਦੀ ਹੈ ਜੋ ਸਹੀ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਅੱਖਰਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਤਾਂ ਜੋ ਵਾਧੂ ਗਣਨਾਵਾਂ ਤੋਂ ਬਿਨਾਂ ਵਰਟੀਕਲ ਸੈਂਟਰਿੰਗ ਕੰਮ ਕਰ ਸਕੇ ਅਤੇ ਆਈਕਨ ਅੱਖਰਾਂ ਦੇ ਬਿਲਕੁਲ ਨਾਲ ਅਲਾਈਨ ਹੋ ਸਕਣ।

ਬ੍ਰਾਊਜ਼ਰ ਸਪੋਰਟ – ਅਜੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਹੈ, ਪਰ ਵਧ ਰਹੀ ਹੈ

ਸਪੋਰਟ ਫਿਲਹਾਲ ਕੁਝ ਹੀ ਬ੍ਰਾਊਜ਼ਰਾਂ ਤੱਕ ਸੀਮਤ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਇਸ ਫੀਚਰ ਨੂੰ ਐਕਸਪੈਰੀਮੈਂਟਲ ਫਲੈਗਸ (experimental flags) ਜਾਂ ਆਪਣੇ ਨਵੇਂ ਰਿਲੀਜ਼ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਅਜੇ ਵੀ ਰਵਾਇਤੀ ਰੈਂਡਰਿੰਗ ਪਾਥ (rendering path) ਦੀ ਵਰਤੋਂ ਹੋਵੇਗੀ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇੱਕ ਗ੍ਰੇਸਫੁੱਲ ਡਿਗ੍ਰੇਡੇਸ਼ਨ ਰਣਨੀਤੀ (graceful degradation strategy) ਦੀ ਲੋੜ ਹੈ। ਚੰਗੀ ਖ਼ਬਰ ਇਹ ਹੈ ਕਿ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਸਾਬਤ ਕਰ ਦਿੱਤਾ ਹੈ ਕਿ ਇਸਦਾ ਲਾਗੂਕਰਨ ਸਥਿਰ ਹੈ, ਅਤੇ ਇਸਦੇ ਮੁੱਖ ਵਰਤੋਂ ਲਈ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾ ਚੁੱਕੀ ਹੈ, ਇਸ ਲਈ ਵਿਆਪਕ ਰੋਲ-ਆਊਟ ਹੋਣ ਵਾਲਾ ਹੈ।

ਕੀ ਦਾਅ 'ਤੇ ਹੈ

ਜੇਕਰ ਕੋਈ ਪ੍ਰੋਜੈਕਟ ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ text-box-trim ਨੂੰ ਅਪਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਤੁਰੰਤ ਫਾਇਦਾ ਇੱਕ ਸਾਫ਼ ਸਟਾਈਲਸ਼ੀਟ (stylesheet) ਹੈ। ਹੁਣ ਹੋਰ ਕੋਈ ਵਿਸ਼ੇਸ਼ line-height ਫਾਰਮੂਲੇ, ਨੈਗੇਟਿਵ ਮਾਰਜਿਨ, ਜਾਂ ਡਿਜ਼ਾਈਨ-ਟੋਕਨ ਐਂਟਰੀਜ਼ ਨਹੀਂ ਚਾਹੀਦੀਆਂ ਜੋ ਸਿਰਫ਼ ਅਦਿੱਖ ਸਪੇਸ ਨੂੰ ਰੋਕਣ ਲਈ ਹੁੰਦੀਆਂ ਹਨ। ਲੰਬੇ ਸਮੇਂ ਲਈ, ਡਿਜ਼ਾਈਨ ਸਿਸਟਮਾਂ ਨੂੰ ਸਰਲ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ: ਇੱਕ ਸਿੰਗਲ "ਟੈਕਸਟ ਬੇਸਲਾਈਨ" ਟੋਕਨ "ਵਰਟੀਕਲ-ਆਫਸੈੱਟ" (vertical-offset) ਵੈਲਯੂਜ਼ ਦੇ ਸਮੂਹ ਦੀ ਜਗ੍ਹਾ ਲੈ ਸਕਦਾ ਹੈ, ਅਤੇ UI ਕੰਪੋਨੈਂਟਸ ਫੌਂਟ ਤਬਦੀਲੀਆਂ ਪ੍ਰਤੀ ਵਧੇਰੇ ਲਚਕੀਲੇ ਬਣ ਜਾਂਦੇ ਹਨ।

ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੇ ਪਹਿਲਾਂ ਹੀ ਪੁਰਾਣੇ ਹੈਕਸ (legacy hacks) ਵਿੱਚ ਬਹੁਤ ਨਿਵੇਸ਼ ਕੀਤਾ ਹੈ, ਬਦਲਣ ਦੀ ਲਾਗਤ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਪ੍ਰੋਪਰਟੀ ਬਾਕਸ-ਮਾਡਲ ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ, ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਸਿੰਗਲ ਕੰਪੋਨੈਂਟ 'ਤੇ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ—ਮੰਨ ਲਓ, ਇੱਕ ਬਟਨ ਲੇਬਲ ਜੋ ਠੀਕ ਨਹੀਂ ਲੱਗ ਰਿਹਾ—ਅਤੇ ਬਾਕੀ ਲੇਆਉਟ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਗੈਪ ਨੂੰ ਗਾਇਬ ਹੁੰਦੇ ਦੇਖ ਸਕਦੇ ਹੋ। ਇਹ ਵਾਧੂ ਪਹੁੰਚ ਤੁਹਾਨੂੰ ਪੂਰੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੇ ਫਾਇਦੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ।

ਦੂਜਾ ਪਹਿਲੂ

ਸਭ ਤੋਂ ਵੱਡੀ ਰੁਕਾਵਟ ਅਸਮਾਨ ਬ੍ਰਾਊਜ਼ਰ ਕਵਰੇਜ ਹੈ। ਜੇਕਰ ਕਿਸੇ ਯੂਜ਼ਰ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ text-box-trim ਨਹੀਂ ਹੈ, ਤਾਂ ਟੈਕਸਟ ਵਾਪਸ ਡਿਫੌਲਟ ਬਾਕਸ ਮਾਡਲ 'ਤੇ ਚਲਾ ਜਾਵੇਗਾ, ਜਿਸ ਨਾਲ ਫਿਰ ਤੋਂ "ਗੋਸਟ ਪੈਡਿੰਗ" ਆ ਜਾਵੇਗੀ। ਇਸ ਲਈ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇੱਕ ਫਾਲਬੈਕ ਰਣਨੀਤੀ (fallback strategy) ਪ੍ਰਦਾਨ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਅਸਮਰਥ ਬ੍ਰਾਊਜ਼ਰਾਂ ਲਈ ਮੌਜੂਦਾ ਲਾਈਨ-ਹਾਈਟ ਐਡਜਸਟਮੈਂਟਸ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ। ਟੂਲਚੇਨਾਂ (ਬਿਲਡ ਪਾਈਪਲਾਈਨਾਂ, CSS-in-JS ਲਾਇਬ੍ਰੇਰੀਆਂ, ਡਿਜ਼ਾਈਨ-ਟੋਕਨ ਜਨਰੇਟਰਾਂ) ਨੂੰ ਵੀ ਨਵੀਂ ਪ੍ਰੋਪਰਟੀ ਨੂੰ ਪਛਾਣਨ ਦੀ ਲੋੜ ਹੈ; ਜਦੋਂ ਤੱਕ ਉਹ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਫੀਚਰ ਨੂੰ ਆਟੋਮੇਟਿਡ ਸਟਾਈਲ ਆਡਿਟ ਵਿੱਚ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

  • ਬ੍ਰਾਊਜ਼ਰ ਰਿਲੀਜ਼: ਮੁੱਖ ਬ੍ਰਾਊਜ਼ਰਾਂ ਦੇ ਰਿਲੀਜ਼ ਨੋਟਸ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ ਕਿ ਉਹ ਕਦੋਂ text-box-trim ਨੂੰ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਚਾਲੂ ਕਰਦੇ ਹਨ।
  • ਡਿਜ਼ਾਈਨ-ਸਿਸਟਮ ਅੱਪਡੇਟਸ: ਉਹ ਟੀਮਾਂ ਜੋ ਟੋਕਨ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਬਣਾਈ ਰੱਖਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ "ਬੇਸਲਾਈਨ" ਟੋਕਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਸ਼ੁਰੂ ਕਰ ਦੇਣੀ

text-box-trim ਅੰਤ ਵਿੱਚ ਵੈੱਬ ਪਲੇਟਫਾਰਮ ਨੂੰ ਟੈਕਸਟ ਨੂੰ ਲੰਬਾਈ (vertically) ਵਿੱਚ ਅਲਾਈਨ ਕਰਨ ਦਾ ਇੱਕ native ਤਰੀਕਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਹੈਕ-ਭਰਪੂਰ ਜੁਗਾੜਾਂ ਤੋਂ ਬਿਨਾਂ ਜਿਨ੍ਹਾਂ ਨੇ ਸਾਲਾਂ ਤੋਂ ਸਟਾਈਲਸ਼ੀਟਾਂ ਨੂੰ ਉਲਝਾਇਆ ਹੋਇਆ ਹੈ। ਜਲਦੀ ਅਪਣਾਉਣ ਵਾਲੇ (Early adopters) ਇੱਕ ਸਿੰਗਲ ਕੰਪੋਨੈਂਟ ਨੂੰ ਸਾਫ਼ ਕਰ ਸਕਦੇ ਹਨ, ਵਿਜ਼ੂਅਲ ਸੁਧਾਰ ਨੂੰ ਸਾਬਤ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਜਿਵੇਂ-ਜਿਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਸਪੋਰਟ ਵਧਦੀ ਹੈ, ਇਸਦੀ ਵਰਤੋਂ ਦਾ ਵਿਸਤਾਰ ਕਰ ਸਕਦੇ ਹਨ। ਇਸ ਨੂੰ ਹੁਣ ਅਣਗੌਲਿਆ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ ਉਸ ਸਮੱਸਿਆ ਲਈ ਅਜਿਹੇ ਨਾਜ਼ੁਕ (brittle) ਕੋਡ ਨੂੰ ਲਿਖਣਾ ਅਤੇ ਬਣਾਈ ਰੱਖਣਾ ਜਾਰੀ ਰੱਖਣਾ ਜਿਸ ਨੂੰ ਹੁਣ ਬ੍ਰਾਊਜ਼ਰ ਹੱਲ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ।