See w3c/dapt#164 - metadata elements whose content is specified only as #PCDATA cannot contain markup, yet it would be an improvement to permit it, for internationalisation. It is possible to use Unicode control characters to signify changes in direction (ltr/rtl) within metadata element contents, but not to signify other styling changes, e.g. ruby, color etc. An ability to do that could be useful in e.g. authoring environments where authors need to make notes - some editing tools allow rich text to be used.
My suggestion would be to permit limited versions of <span> and <br>, but not timings, and therefore not animations. It seems like unnecessary complexity to include <div> and <p>, but I could be persuaded otherwise.
See also https://www.w3.org/TR/international-specs/#bidi_inline_change for the motivation behind allowing markup; in particular, if/while we do not allow markup, we should require support for Unicode bidirectional control characters in elements whose character content is only #PCDATA; no attributes appear to be affected by this constraint since they do not contain unconstrained text content that needs to support different direction scripts.
See w3c/dapt#164 - metadata elements whose content is specified only as
#PCDATAcannot contain markup, yet it would be an improvement to permit it, for internationalisation. It is possible to use Unicode control characters to signify changes in direction (ltr/rtl) within metadata element contents, but not to signify other styling changes, e.g. ruby, color etc. An ability to do that could be useful in e.g. authoring environments where authors need to make notes - some editing tools allow rich text to be used.My suggestion would be to permit limited versions of
<span>and<br>, but not timings, and therefore not animations. It seems like unnecessary complexity to include<div>and<p>, but I could be persuaded otherwise.See also https://www.w3.org/TR/international-specs/#bidi_inline_change for the motivation behind allowing markup; in particular, if/while we do not allow markup, we should require support for Unicode bidirectional control characters in elements whose character content is only
#PCDATA; no attributes appear to be affected by this constraint since they do not contain unconstrained text content that needs to support different direction scripts.