<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>CSS on Duma's website</title><link>https://dumaron.github.io/tags/css/</link><description>Recent content in CSS on Duma's website</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 27 Aug 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://dumaron.github.io/tags/css/index.xml" rel="self" type="application/rss+xml"/><item><title>&lt;code&gt;datalist&lt;/code&gt; for range inputs</title><link>https://dumaron.github.io/notes/tils/2024-08-27_datalist_for_range_inputs/</link><pubDate>Tue, 27 Aug 2024 00:00:00 +0000</pubDate><guid>https://dumaron.github.io/notes/tils/2024-08-27_datalist_for_range_inputs/</guid><description>&lt;p&gt;The &lt;code&gt;datalist&lt;/code&gt; tag has surprised me at least a couple time already. While I still consider native HTML inputs as inadequate and too rigid, I admit that thanks to the &lt;code&gt;datalist&lt;/code&gt; tag the UX can improve a bit.&lt;/p&gt;&#10;&lt;p&gt;Today I was how far the native range inputs are from for &#10;&#10;&lt;a href="https://eui.elastic.co/#/forms/range-sliders" rel="noopener" target="_blank"&gt;ElasticUI range inputs&lt;/a&gt;, the one I currently use. I stumbled upon the MDN Web docs page and particularly &#10;&#10;&lt;a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range#list" rel="noopener" target="_blank"&gt;on the &lt;code&gt;list&lt;/code&gt; attribute&lt;/a&gt;: it can contain the &lt;code&gt;id&lt;/code&gt; of a &lt;code&gt;datalist&lt;/code&gt; component and to enhance the user experience of the input. It seems the only three ways these two tags can interact are:&lt;/p&gt;</description></item><item><title>&lt;code&gt;:has()&lt;/code&gt; pseudo-selector and current node parent</title><link>https://dumaron.github.io/notes/tils/2024-02-02_has_selector_and_node_parent/</link><pubDate>Fri, 02 Feb 2024 00:00:00 +0000</pubDate><guid>https://dumaron.github.io/notes/tils/2024-02-02_has_selector_and_node_parent/</guid><description>&lt;p&gt;Today I was finally able to use the &lt;code&gt;:has()&lt;/code&gt; pseudo-selector. I&amp;rsquo;ve heard about that in a superficial way through articles and comments, but I&amp;rsquo;ve never it in person.&lt;/p&gt;&#10;&lt;p&gt;Today at work I needed to implement a workaround, which consisted in &lt;strong&gt;setting some CSS rules to the parent of the current node&lt;/strong&gt;. I&amp;rsquo;ve always thought it was impossible to achieve, but good folks updated &#10;&#10;&lt;a href="https://stackoverflow.com/questions/1014861/is-there-a-css-parent-selector" rel="noopener" target="_blank"&gt;this old question on StackOverflow&lt;/a&gt;, explaining how &lt;code&gt;:has()&lt;/code&gt; could have helped.&lt;/p&gt;</description></item><item><title>Better viewport units for responsive design</title><link>https://dumaron.github.io/notes/tils/2024-02-01_better_viewport_units_for_responsive_design/</link><pubDate>Thu, 01 Feb 2024 00:00:00 +0000</pubDate><guid>https://dumaron.github.io/notes/tils/2024-02-01_better_viewport_units_for_responsive_design/</guid><description>&lt;p&gt;&lt;strong&gt;The issue is&lt;/strong&gt;: using &lt;code&gt;100vh&lt;/code&gt; as a rule to measure the whole viewport height is just faulty on mobile. Ona side note, I belive most of the times this is a bad idea, and people actually want something different, but let&amp;rsquo;s avoid this topic.&lt;/p&gt;&#10;&lt;p&gt;I encountered this issue again today, where one of the web apps I work on has &lt;code&gt;100vh&lt;/code&gt; but now has also the need to be more mobile-friendly.&lt;/p&gt;</description></item><item><title>Child rule does not mean child element</title><link>https://dumaron.github.io/notes/tils/2024-01-15_child_rule_does_not_mean_child_element/</link><pubDate>Mon, 15 Jan 2024 00:00:00 +0000</pubDate><guid>https://dumaron.github.io/notes/tils/2024-01-15_child_rule_does_not_mean_child_element/</guid><description>&lt;p&gt;I always tought that, either in SASS or in native CSS nested selector, it was possible only to refine a selector by appending attributes of child nodes. It turns out it isn&amp;rsquo;t so.&lt;/p&gt;&#10;&lt;p&gt;In other words, whenever the &lt;code&gt;&amp;amp;&lt;/code&gt; is used in selectors it&amp;rsquo;s possible to write &lt;code&gt;body &amp;amp;&lt;/code&gt; and it&amp;rsquo;ll create a legit selector. I expected that only refinements like &lt;code&gt;&amp;amp; .some-children-class&lt;/code&gt; would work.&lt;/p&gt;&#10;&lt;p&gt;This is a partial example to show the mechanism: the haiku is green, while I would have expected it to be blue.&lt;/p&gt;</description></item></channel></rss>