<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: extra88</title><link>https://news.ycombinator.com/user?id=extra88</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 25 May 2026 01:28:47 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=extra88" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by extra88 in "On The <dl> (2021)"]]></title><description><![CDATA[
<p>The entire purpose of <b> <i>was</i> what it looked like. They changed its definition to not be about what it looked like but why an author might make it look that way, i.e. to bring attention to it. The representation flows from the motivation, there's no need to embed a look in the definition.</p>
]]></description><pubDate>Sun, 24 May 2026 15:41:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=48258174</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48258174</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48258174</guid></item><item><title><![CDATA[New comment by extra88 in "On The <dl> (2021)"]]></title><description><![CDATA[
<p>Because the elements already exist. When the elements were invented and defined, CSS didn't exist and authors had to use elements to make presentational changes.
When HTML5 was defined, CSS was well established and it was an opportunity to update element descriptions to get rid of specific presentational qualities.<p>There are lots of elements, if you don't find some of them useful, don't use them. Other people may find uses for the distinctions; even if they use distinctive styling for them all, they may need to document why they're used, not just for all the authors but for the audience as well; clearly we can't expect developers to know what all the elements are for so that's doubly true for the audience.</p>
]]></description><pubDate>Sat, 23 May 2026 23:43:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=48252754</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48252754</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48252754</guid></item><item><title><![CDATA[New comment by extra88 in "On The <dl> (2021)"]]></title><description><![CDATA[
<p>In practice today, that's fine. Typically authors have a hard time differentiating what "emphasis," "importance," and "bring attention to" mean to them. Therefore, nothing conveys a distinction by default.</p>
]]></description><pubDate>Sat, 23 May 2026 19:34:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=48250640</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48250640</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48250640</guid></item><item><title><![CDATA[New comment by extra88 in "On The <dl> (2021)"]]></title><description><![CDATA[
<p>lol, you should actually read the HTML spec, there are good explanations of all the elements. The whole point of defining semantics is that elements have meaning <i>independent</i> of their default appearance (or any appearance).<p>> I need to learn more about web accessibility, but if you completely ignore it (and other sane practices) HTML looks really simple.<p>Everything looks really simple when you ignore vast amounts of the subject and nuance.<p>Your rules don't mention keyboard or focus behavior, the only mention of either is the association between <label> and its <input>. <output> does have functionality, it's an HTML-native ARIA live region (that can be associated with a <label>).<p><a href="https://html.spec.whatwg.org/multipage/" rel="nofollow">https://html.spec.whatwg.org/multipage/</a></p>
]]></description><pubDate>Sat, 23 May 2026 19:28:12 +0000</pubDate><link>https://news.ycombinator.com/item?id=48250560</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48250560</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48250560</guid></item><item><title><![CDATA[New comment by extra88 in "On The <dl> (2021)"]]></title><description><![CDATA[
<p>Well, it took about a decade for web standards to become a real thing and a lot longer for Web Platform Tests to come to be. Still, while there are lots of tests for DOM construction and visual rendering, testing construction of the accessibility tree is lacking (also keyboard interaction testing).<p>And that's just for browsers, there's no shared spec for the operating system accessibility APIs the browsers' accessibility tree has to be translated into or how screen readers (and other assistive technologies) will use the OS's APIs.</p>
]]></description><pubDate>Sat, 23 May 2026 19:06:40 +0000</pubDate><link>https://news.ycombinator.com/item?id=48250362</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48250362</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48250362</guid></item><item><title><![CDATA[New comment by extra88 in "On The <dl> (2021)"]]></title><description><![CDATA[
<p>Eh, it's fine, elements should be defined for what they mean, not what they look like. The explanation and distinctions made between <b> and other elements (<i>, <em>, <strong>) make sense.<p>The suggested (not obligatory) user agent styling for <b> is `font-weight: bolder` an agent or authors could use lots of different things to bring attention to what the element contains and treat it differently from <strong>.<p><a href="https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-b-element" rel="nofollow">https://html.spec.whatwg.org/multipage/text-level-semantics....</a><p><a href="https://html.spec.whatwg.org/multipage/rendering.html#phrasing-content-3" rel="nofollow">https://html.spec.whatwg.org/multipage/rendering.html#phrasi...</a></p>
]]></description><pubDate>Sat, 23 May 2026 18:51:21 +0000</pubDate><link>https://news.ycombinator.com/item?id=48250201</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48250201</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48250201</guid></item><item><title><![CDATA[New comment by extra88 in "On The <dl> (2021)"]]></title><description><![CDATA[
<p>There are already well-defined rules, you just don't like some of the rules, e.g. you can't (today) style <select> options. Keyboard navigation <i>is</i> free as long as you follow the rules about which elements are focusable.<p>You shouldn't have to care about screen readers the same as you shouldn't have to care which browser someone uses but you always have to care about people; people who can't see or hear what you create, people who can operate a keyboard (or keyboard-equivalent) but not a mouse or touchscreen, people who can use a touchscreen but not a physical keyboard, etc.</p>
]]></description><pubDate>Sat, 23 May 2026 18:40:08 +0000</pubDate><link>https://news.ycombinator.com/item?id=48250094</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48250094</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48250094</guid></item><item><title><![CDATA[New comment by extra88 in "On The <dl> (2021)"]]></title><description><![CDATA[
<p>Good news! `.ariaNotify()` is basically a real implementation of your hypothetical document.speakText.<p><a href="https://developer.mozilla.org/en-US/docs/Web/API/Element/ariaNotify" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/Element/ari...</a></p>
]]></description><pubDate>Sat, 23 May 2026 18:31:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=48249996</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48249996</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48249996</guid></item><item><title><![CDATA[New comment by extra88 in "Moving away from Tailwind, and learning to structure my CSS"]]></title><description><![CDATA[
<p>I think popover and invoker commands with polyfills are already the way to go. The polyfills are small (and if you only want to use the "show-modal" invoker, it's like 10 lines to feature detect and polyfills just that).<p>Many good uses of popover really needs anchor positioning. There's a polyfill for that as well but it's not small.</p>
]]></description><pubDate>Sun, 17 May 2026 21:57:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=48173552</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48173552</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48173552</guid></item><item><title><![CDATA[New comment by extra88 in "Moving away from Tailwind, and learning to structure my CSS"]]></title><description><![CDATA[
<p>Note the word "if" at the beginning.</p>
]]></description><pubDate>Sun, 17 May 2026 21:43:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=48173455</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48173455</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48173455</guid></item><item><title><![CDATA[New comment by extra88 in "Moving away from Tailwind, and learning to structure my CSS"]]></title><description><![CDATA[
<p>Sure. I don't know where you're claiming that misinformation is coming from, it doesn't have anything to do with what I wrote. I was referring to CSS properties that affect the accessibility tree.</p>
]]></description><pubDate>Sun, 17 May 2026 00:19:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=48165002</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48165002</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48165002</guid></item><item><title><![CDATA[New comment by extra88 in "HTML Lists"]]></title><description><![CDATA[
<p><dialog> is awesome, especially when combined with Invoker commands or `popover`.
<menu> does nothing, it's just another name for <ul>.</p>
]]></description><pubDate>Sat, 16 May 2026 23:16:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=48164629</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48164629</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48164629</guid></item><item><title><![CDATA[New comment by extra88 in "HTML Lists"]]></title><description><![CDATA[
<p>Because for the user experience, it is identical to <ul>. Use <menu> if it helps you to understand your code but in the browser's accessibility tree and in all other respects, it's just an unordered list.<p>Conveying that something is a list of actions requires adding ARIA attributes. The article mentions `role=menu` but that's not enough, each item also needs the `menuitem` role. The WAI Authoring Practices Guide explains the roles and interaction expectations; don't copy their coded examples and definitely don't use the roles for navigation menus.<p><a href="https://www.w3.org/WAI/ARIA/apg/patterns/menubar/" rel="nofollow">https://www.w3.org/WAI/ARIA/apg/patterns/menubar/</a></p>
]]></description><pubDate>Sat, 16 May 2026 23:14:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=48164621</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48164621</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48164621</guid></item><item><title><![CDATA[New comment by extra88 in "Moving away from Tailwind, and learning to structure my CSS"]]></title><description><![CDATA[
<p>WAI's APG patterns exist to document how ARIA attributes <i>should</i> work, they don't advocate for them to be used in place HTML elements. They also don't test to confirm that they actually work in browsers or with assistive technologies (some specific patterns are fine). For web developers, they're helpful for documenting expected keyboard interaction support and other norms.<p>Are you still coding to support Internet Explorer? All browsers have supported details/summary since an Edge switched to Chromium in 2020.<p><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...</a></p>
]]></description><pubDate>Sat, 16 May 2026 19:27:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=48163015</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48163015</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48163015</guid></item><item><title><![CDATA[New comment by extra88 in "Moving away from Tailwind, and learning to structure my CSS"]]></title><description><![CDATA[
<p>I'm not familiar with that old tale about Zeldman. It's true that assistive technologies don't know about CSS class names but CSS absolutely can affect a non-sighted screen reader user's experience.<p>I don't use Tailwind so I don't know if it makes it easier or harder to do the right thing when needing to hide something from everyone or only visually hiding something. Because it's CSS, it can't take care of only hiding something from assistive technologies.</p>
]]></description><pubDate>Sat, 16 May 2026 19:15:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=48162919</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48162919</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48162919</guid></item><item><title><![CDATA[New comment by extra88 in "Moving away from Tailwind, and learning to structure my CSS"]]></title><description><![CDATA[
<p>If Tailwind lends itself to using pixels instead of relative units for things that should be relative (like font-size, line-height, etc.), that's a problem.
For those users, the HTML elements matter less unless they're savvy users who have custom user stylesheets to selectively adjust the appearance of content instead of changing everything on the page by zooming (e.g. make links, buttons, paragraphs, list items bigger and/or a different font or weight).</p>
]]></description><pubDate>Sat, 16 May 2026 19:03:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=48162815</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48162815</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48162815</guid></item><item><title><![CDATA[New comment by extra88 in "Stitch together lots of little HTML pages with navigations for interactions"]]></title><description><![CDATA[
<p>That's less accessible and capable than the popover / dialog solution.</p>
]]></description><pubDate>Tue, 05 May 2026 02:55:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=48017575</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=48017575</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48017575</guid></item><item><title><![CDATA[New comment by extra88 in "Hugo's New CSS Powers"]]></title><description><![CDATA[
<p>BTW, there's a glitch in your code snippet syntax highlighting; in Light mode, the 'p' selector is remaining an unreadable yellow.</p>
]]></description><pubDate>Thu, 02 Apr 2026 22:41:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=47621138</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=47621138</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47621138</guid></item><item><title><![CDATA[New comment by extra88 in "The Legibility of Serif and Sans Serif Typefaces (2022)"]]></title><description><![CDATA[
<p>That's only a problem with some sans-serif fonts. This very site is using a sans-serif and the capital 'I' has bars in either end so it's not confused with 'l'.<p>Some sans-serif fonts do add little flourishes to some letters, like 'l', to further distinguish them.</p>
]]></description><pubDate>Fri, 27 Mar 2026 12:14:32 +0000</pubDate><link>https://news.ycombinator.com/item?id=47541766</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=47541766</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47541766</guid></item><item><title><![CDATA[New comment by extra88 in "Ball Pit"]]></title><description><![CDATA[
<p>Yeah, it seems fine on my iPhone 13 running Safari 18. It's not warming up.<p>Some ball shadows look kind of grainy but moving my finger around moves the balls around.</p>
]]></description><pubDate>Wed, 25 Mar 2026 23:35:42 +0000</pubDate><link>https://news.ycombinator.com/item?id=47524775</link><dc:creator>extra88</dc:creator><comments>https://news.ycombinator.com/item?id=47524775</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47524775</guid></item></channel></rss>