Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On The (2021)

benmyers.dev

Post reply on HN
Print view View original

101–110 of 138 posts

Re: On The <dl> (2021)

#101

Post by sunshowers »

extra88 wrote: post #99
sunshowers wrote: post #92

Earlier quoted context omitted.

I write most of my content in markdown or asciidoc and I don't pay attention to whether it's b or strong :)

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.

So then what's the point of making this distinction? I would like to see surveys of how many people actually author content in forms that differentiate between b and strong.

Re: On The <dl> (2021)

#102

Post by sedatk »

enriquto wrote: post #24
Demiurge wrote: post #19

I love DL. I think tables, at least in the past, were misused as DLs even more in the past and the inconvenience of the table markup is even worse than a bunch of divs.

It's not that inconvenient if you omit unnecessary closing tags: first second what ever I find it simpler and cleaner than any of the markdown table markups

> if you omit unnecessary closing tags

As someone who had written lots of XHTML in the past, not having closing tags makes my eyes twitch like Scrat in Ice Age. I even occasionally write `
` like `
` out of habit.

Re: On The <dl> (2021)

#103

Post by bulatb »

bulatb wrote: post #75
shermantanktop wrote: post #68

Earlier quoted context omitted.

Oh that’s great. It’s an opinionated view that focused strictly on the behavior of the tags wrt layout and appearance. I’ve noticed that discussions of semantic meaning of tags often contain the word “feel.” Nothing wrong with that, taste matters, but it does point to the non-functional goals that are being pursued when people disagree. vs - they are both ordered, because markup is ordered. One gets decorated differe…

A is a list of things whose order makes no difference to its meaning. Rearranging a would change the presentation, not the information. Rearranging an would change both. Players Alice Bob Carol Leaderboard Bob Alice Carol

Too late to edit now, but I should mention putting titles in a list like that isn't valid. It's just to shorten the example.

Re: On The <dl> (2021)

#104

Post by NooneAtAll3 »

brewmarche wrote: post #72
chrismorgan wrote: post #31

> This is incorrect: 1. has no corresponding ( viz. implicit) role, but can be given the role group, list, none or presentation https://w3c.github.io/html-aria/#el-dl >. 2. You’re only allowed to define aria-label on elements that have a compatible role, implicit or explicit https://w3c.github.io/html-aria/#docconformance-naming >. 3. aria-label is allowed on all but a handful of roles https://www.w3.org/TR/wai-aria-…

Your comment put me on a side quest to research the differences between i.e., e.g., viz. and sc. and I have to admit that I’m still not 100% sure

i.e. == aka == in other words

e.g. == f.e., for example

Re: On The <dl> (2021)

#106

Post by JohnKemeny »

theodpHN wrote: post #97

List history (listory?) lesson, kids: As the link below to a 1985 IBM mainframe DCF/GML manual shows, DL-DT-DD have been a thing since before the web. In addition to Definition lists (DL), the 40+ year-old documentation describes Glossary lists (GL), Ordered lists (OL), Unordered lists (UL), and Simple lists (SL). ibm :: 370 :: DCF :: SH35-0050-2 Document Composition Facility Generalized Markup Language Implementatio…

Isn't it description list?

Re: On The <dl> (2021)

#107

Post by bulatb »

shermantanktop wrote: post #100
bulatb wrote: post #75

Earlier quoted context omitted.

A is a list of things whose order makes no difference to its meaning. Rearranging a would change the presentation, not the information. Rearranging an would change both. Players Alice Bob Carol Leaderboard Bob Alice Carol

Exactly. “Unordered” implies “reordering doesn’t change meaning.” And yet that’s already implicit in the bullets (vs numbers). So is it a decoration hint? Or is it actually semantic? And what system is interpreting the semantics rather than the visual presentation?

HyperText Markup Language is semantic. You're marking up a document to show what information it contains, where it contains it, and how it relates to other documents or information. Reading markup causes browsers to display things, but that's incidental.

In theory.

In practice, no one cares about semantics and the choice of tags is based on how a target set of browsers happens to display them.

Your question about who interprets markup is exactly right. In theory, you have no idea. Maybe it's a browser, maybe it's assistive software, maybe it's a browser printing, maybe it's some custom knowledge base with different views of documents for different users. In theory, you're supporting all of that by only marking up semantics and allowing the consumer to interpret them, because there isn't one right answer.

In practice, your client is Chrome.

In theory, that's irrelevant because you're using CSS to style semantic markup so it works in Chrome and still makes sense to other clients.

In practice, you're writing a web application, using a framework, and nothing in the stack wants you to do that.

Re: On The <dl> (2021)

#108

Post by Joker_vD »

sunshowers wrote: post #101
extra88 wrote: post #99

Earlier quoted context omitted.

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.

So then what's the point of making this distinction? I would like to see surveys of how many people actually author content in forms that differentiate between b and strong.

What, you don't know what's the difference between "emphasis" and "bringing attention to"? Shame on you, shame on you: you're unworthy to write HTML.

The difference, of course, is that one is a Latin word, and the other is an English phrase with the same meaning. But they're different words, so different tags. It's all completely rational and logical, and if you don't see the logic and/or reason, well: you're unworthy to write HTML. See Figure 1.

P.S. I love this ancient "see figure 1" meme. It's originated in the early 80s, and still as relevant as ever, and probably will be forever.

    Please stop submitting SPR's.  This is our system.  We designed
    it, we built it, and we use it more than you do.  If there are some
    features you think might be missing, if the system isn't as effective
    as you think it could be, TOUGH!  Give it back, we don't need you.
    See figure 1.

           ---------------------------
           !            -            !
           !           { }           !
           !           | |           !
           !           | |           !
           !        .-.! !.-.        !
           !      .-!  ! !  !.-.     !
           !      ! !       !  ;     !
           !      \           ;      !
           !       \         ;       !
           !        !       :        !
           !        !       |        !
           !        |       |        !
           !                         !
           ---------------------------
                     Figure 1.

Re: On The <dl> (2021)

#109

Post by pverheggen »

redmatter wrote: post #50
chrismorgan wrote: post #31

> This is incorrect: 1. has no corresponding ( viz. implicit) role, but can be given the role group, list, none or presentation https://w3c.github.io/html-aria/#el-dl >. 2. You’re only allowed to define aria-label on elements that have a compatible role, implicit or explicit https://w3c.github.io/html-aria/#docconformance-naming >. 3. aria-label is allowed on all but a handful of roles https://www.w3.org/TR/wai-aria-…

Wow I have never noticed that, thanks for the heads up! Out of curiosity, would you put `role="listitem"` on ` ` elements that wrap the ` ` && ` ` elements? It looks like `role="listitem"` is allowed on the ` ` element, but that doesn't feel like it would be accurate in the case where multiple ` ` elements are grouped together, and I'm not sure if that would mess with how the element is interpreted natively as as ter…

I pulled up some of those spec's examples in Chrome and viewed the accessibility tree, and weirdly it assigns an implicit role of `term`, even though the spec says that should be `listitem` and should be `term`. I didn't check FF or Safari but I would not be surprised if they did something different.

Given the spotty screen reader support for dt/dd to begin with, I'd steer clear of using multiple `` s if a11y is top priority, and just modify your content to have one dt per dd. Your single dt text could be "X or Y", repeat the definition twice, etc.

If you're familiar with Jakob's Law, it applies to a11y too, so stick with what users might have seen on other sites.

Re: On The <dl> (2021)

#110

Post by teaearlgraycold »

kqp wrote: post #62

This is going to be unpopular here, but life became easier when I quit trying to write semantic HTML. It’s just poorly designed, I’m sorry. Every time I’ve reached for a I’ve eventually regretted it because I wanted multiple levels of wrappers, or a divider between sections, or an icon, or a heading spanning multiple key-value pairs, etc. They make this stuff with some flexibility but nowhere near enough to actually…

I feel similarly about HTTP. The protocol maps really well to resource stores (stuff like S3). GET, PUT, DELETE all make sense. HTTP status codes are built exactly for this use case as well. But as web developers we're mostly not developing resource stores. Those are highly generic and can be built once and used by millions of apps. Most of the time someone is writing code that interacts with HTTP they are performing RPC. You can go for GraphQL, gRPC, or many other RPC systems that just shirk the whole thing. They make everything use a POST to a single endpoint and add another layer of abstraction so you don't need to return a 4XX/5XX error for some highly application-specific situation.

It's clear the RFC writers got a little out of hand. "402 Payment Required", "407 Proxy Authentication Required", "508 Loop Detected" look to me like attempts to work in functionality specific to certain types of apps or deployments. Why do these RFC authors get their specific needs implemented into the bedrock of the web and then expect me to find where my needs happen to overlap and then tuck every aspect specific to my app into "400 Bad Request" or "500 Internal Server Error"? Every time I see a web app actually utilize more than the bare minimum of HTTP status codes I roll my eyes. Put that shit into the application layer. The protocol wasn't made for you. It was made for LAMP-stack apps serving mostly static assets.

Post reply on HN