HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
jevko
specifications
HTML2022–2022
jevko / specifications

specifications

Specifications related to Jevko.

2Distinct people
6Mentions
0Explicit recommenders
10GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Specifications related to Jevko.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:28:18 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by day6 dated mentions

Observed mentions: 2022-10-18 21:54:16 UTC to 2022-11-04 01:44:50 UTC.

012022-10-18 00:00:00 UTC to 2022-10-19 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsOct 182022-10-19 00:00:00 UTC to 2022-10-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-20 00:00:00 UTC to 2022-10-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-21 00:00:00 UTC to 2022-10-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-22 00:00:00 UTC to 2022-10-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-23 00:00:00 UTC to 2022-10-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-24 00:00:00 UTC to 2022-10-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-25 00:00:00 UTC to 2022-10-26 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-10-26 00:00:00 UTC to 2022-10-27 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsOct 262022-10-27 00:00:00 UTC to 2022-10-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-28 00:00:00 UTC to 2022-10-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-29 00:00:00 UTC to 2022-10-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-10-30 00:00:00 UTC to 2022-10-31 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-10-31 00:00:00 UTC to 2022-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-01 00:00:00 UTC to 2022-11-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-02 00:00:00 UTC to 2022-11-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-11-03 00:00:00 UTC to 2022-11-04 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-11-04 00:00:00 UTC to 2022-11-05 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsNov 4

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Oct 182022-10-18 00:00:00 UTC2022-10-19 00:00:00 UTC101
Oct 192022-10-19 00:00:00 UTC2022-10-20 00:00:00 UTC000
Oct 202022-10-20 00:00:00 UTC2022-10-21 00:00:00 UTC000
Oct 212022-10-21 00:00:00 UTC2022-10-22 00:00:00 UTC000
Oct 222022-10-22 00:00:00 UTC2022-10-23 00:00:00 UTC000
Oct 232022-10-23 00:00:00 UTC2022-10-24 00:00:00 UTC000
Oct 242022-10-24 00:00:00 UTC2022-10-25 00:00:00 UTC000
Oct 252022-10-25 00:00:00 UTC2022-10-26 00:00:00 UTC101
Oct 262022-10-26 00:00:00 UTC2022-10-27 00:00:00 UTC101
Oct 272022-10-27 00:00:00 UTC2022-10-28 00:00:00 UTC000
Oct 282022-10-28 00:00:00 UTC2022-10-29 00:00:00 UTC000
Oct 292022-10-29 00:00:00 UTC2022-10-30 00:00:00 UTC000
Oct 302022-10-30 00:00:00 UTC2022-10-31 00:00:00 UTC101
Oct 312022-10-31 00:00:00 UTC2022-11-01 00:00:00 UTC000
Nov 12022-11-01 00:00:00 UTC2022-11-02 00:00:00 UTC000
Nov 22022-11-02 00:00:00 UTC2022-11-03 00:00:00 UTC000
Nov 32022-11-03 00:00:00 UTC2022-11-04 00:00:00 UTC101
Nov 42022-11-04 00:00:00 UTC2022-11-05 00:00:00 UTC101

What Hacker News says

1 sources
Yes, in Elm or Lisp this would be problematic. In this syntax though it isn't. Anything between brackets like this: [foo bar baz] that does not contain any nested brackets is a simple tree which contains "foo bar baz" as its sole value (called a suffix). In this syntax whitespace is not a separator. So you can store a single piece of text in such a simple tree. Now if you want to have 3 pieces of text you do this: [foo][bar][baz] 3 simple trees together -- they are subtrees of a top-level tree. If you want to have 3 of these you do this: [[foo][bar][baz]] [[foo][bar][baz]] [[foo][bar][baz]] The linebreaks don't change the tree structure, they are inserted purely for readability. There are no implicit commas or anything. Each subtree is also potentially a name-value pair. If you insert names before the opening brackets: [x [
Read the rest
foo] y [bar] z [baz]] You have 3 pairs. The names themselves are also pieces of text (whitespace is not a separator), so you can have names like: [my x [foo] your y [bar] their z [baz]] Still 3 pairs. Now to turn trees like this into something useful, for example XML/SVG, you'd do a little bit of processing on them, e.g. you could transform the names like so: my x [foo] your y [bar] their z [baz] into: <myX>foo</myX><yourY>bar</yourY><theirZ>bar</theirZ> in this manner you could transform: svg [x=[0px] y=[0px] view box=[0 0 21 21] path [ fill=[#FFF] stroke=[#146AFF] stroke width=[2] d=[M11.1,1.4l2.4,...] ]] into: <svg x="0px" y="0px" viewBox="0 0 21 21"><path fill="#FFF" stroke="#146AFF" strokeWidth="2" d="M11.1,1.4l2.4,..." ></path></svg> Notice that here I used a convention where names which end with "=" become XML attributes, whereas names which don't become children. I have used the same convention here (except I don't bother with transforming names with spaces into camelCase): https://github.com/jevko/specifications/blob/master/easyjevk... to generate this HTML file: https://htmlpreview.github.io/?https://github.com/jevko/spec... Now I intend to write specifications that codify conventions like this into different formats based on this fundamental syntax of square brackets. It can be useful for all kinds of things. Its advantage is extreme simplicity and flexibility. BTW, for clarity I have to say that the format that I used here: https://news.ycombinator.com/item?id=32995047 does a bit more transformations -- it actually sometimes treats whitespace as a separator (e.g. in `svg width[391]` space is a separator). That allows for extreme conciseness, but is not necessary and introduces complexity.
In SVGs as Elm Code

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.