You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that attr() has a type model that makes attributes more accessible to and usable in CSS, let’s consider whether there should be something very similar for element content: element(), node(), content() or text(). Since there is just one content, it would not need an attribute name as one of its arguments, but perhaps the nesting level to consider might be helpful, defaulting either to top or all.
I do not see any use cases for complex nested element content, which is why I think it should all be flattened to a space-normalized string, but I believe there would be some use cases for simple textual or (almost) numeric content. Take, for instance, cell content in data tables; it may be helpful – and within the domain of styling – to convert the data to a shorter representation more suitable for the available width (with MQ/CQ), e.g. custom text ellipsing, truncating floating point numbers, converting to scientific/engineering notation, scaling with SI prefixes, brief or expanded date notation, localizable relative time keywords, conversion to (image) symbols or emojis …
Some of this would require additional functions for string and number manipulation within CSS, but some would be possible today.
Some text preprocessors, e.g. from Markdown to HTML+CSS, convert code spans that contain only a valid CSS color to a search representation of that color.
Since most use cases I can think of would write the result back with the content property, this could as well be part of the Content Module, which already has the related contents keyword.
The text was updated successfully, but these errors were encountered:
Now that
attr()
has a type model that makes attributes more accessible to and usable in CSS, let’s consider whether there should be something very similar for element content:element()
,node()
,content()
ortext()
. Since there is just one content, it would not need an attribute name as one of its arguments, but perhaps the nesting level to consider might be helpful, defaulting either to top or all.I do not see any use cases for complex nested element content, which is why I think it should all be flattened to a space-normalized string, but I believe there would be some use cases for simple textual or (almost) numeric content. Take, for instance, cell content in data tables; it may be helpful – and within the domain of styling – to convert the data to a shorter representation more suitable for the available width (with MQ/CQ), e.g. custom text ellipsing, truncating floating point numbers, converting to scientific/engineering notation, scaling with SI prefixes, brief or expanded date notation, localizable relative time keywords, conversion to (image) symbols or emojis …
Some of this would require additional functions for string and number manipulation within CSS, but some would be possible today.
Some text preprocessors, e.g. from Markdown to HTML+CSS, convert code spans that contain only a valid CSS color to a search representation of that color.
Since most use cases I can think of would write the result back with the
content
property, this could as well be part of the Content Module, which already has the relatedcontents
keyword.The text was updated successfully, but these errors were encountered: