Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Web Components for Dynamic Scripture References (shurmer.family)
57 points by jshurmer on May 13, 2019 | hide | past | favorite | 8 comments



This doesn’t work properly in Firefox: `event.path` isn’t a thing, so clicking to open or close does nothing.

When dealing with Web Components, I think it’s worthwhile for you to consider their degraded state, for the benefit of while they’re loading, and if they fail to load (e.g. JS disabled, too-old browser, or a poor network connection). I personally have uMatrix installed and blocking most third-party JS, so your code from cdn.jsdelivr.net didn’t get loaded, and the content was just completely missing.

How might this be improved, then?

  <scripture-passage api="crosswayApi" reference="Acts 17:24-25"></scripture-passage>
The answer is clear to me: shift the reference from an attribute into a text node:

  <scripture-passage api="crosswayApi">Acts 17:24-25</scripture-passage>
How about the list?

  <scripture-list
    api="crosswayApi"
    reference-list='["2 Timothy 1:9", "James 1:18"]'
  ></scripture-list>
Semantically this feels odd: it’s one element, but it should be multiple. How about this instead:

  <scripture-list api="crosswayApi">
    <scripture-passage>2 Timothy 1:9</scripture-passage>
    <scripture-passage>James 1:18</scripture-passage>
  </scripture-list>
I’d even suggest considering whether to use <ul> and/or <li> for these, in one way or another. If not, perhaps it might be worthwhile having <scripture-list> strip all text nodes inside it, considering only <scripture-passage> elements, and get in the habit of putting a semicolon after passages that aren’t the last in the list: that way the fully-degraded experience will be “2 Timothy 1:9; James 1:18”.

The `api` attribute feels more verbose than is ideal: I imagine that most uses will have only a single value through the page. Therefore I recommend making it optional, with some other way of specifying a default, with my first-thought strawman syntax being <meta name="scripture-api" value="crosswayApi">. (You may have observed that I took the liberty of lifting it from the passage up to the list in the last example I showed.)


Yes, thanks for pointing out the `event.path` problem. It's been resolved now.

Good thoughts on the graceful degradation. I'll put some thought into it. As well as the API reference!

Ya, I played around with nesting <scripture-passage>es inside the <scripture-list>, but couldn't find a good way to access the text nodes inside the passage. Prob just needed a bit more work though, I do like it better from a semantic POV.


When all you want is the text, disregarding any further markup, just use `.textContent`. Otherwise, look through `childNodes` for any with nodeType 3 (Node.TEXT_NODE).


Riffing off this a little, it's kinda odd that there are two different ways of specifying multiple passages, depending on the book.

Shouldn't:

    <scripture-passage
        api="crosswayApi"
        reference="Genesis 45:5-8, Genesis 50:20">
    </scripture-passage>
Really be a scripture-list?


It could also be a scripture-list, yes. It depends on the UI you want, has nothing to do with whether the references are from the same book. If you want a list of different passages where each can be expanded separately then use scripture-list. If you want them to always show together use this version . I could change things to make that more clear.


There's an obvious joke here about inconsistencies being par for the course.


Your `api` attribute recommendation is nice. I've seen similar attributes needed to specify access keys, like for the <google-map> element. <meta name="google-maps-key" value="..."> is a lot nicer.

event.path is from the "v0" APIs, that should be event.composedPath().


Thanks for the feedback people!

I started this originally to learn Web Components, and for my own personal website (jordan.shurmer.family). I assume other devs out there would benefit from this and have a lot of contributions to add as well, glad it's getting a bit of attention!




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: