Probably because all of CSS uses 1-index (ex: :nth-child)

Correct answer.

Ultimately these are just conventions. There are probably good reasons for them, too. For example having [a,b)* allows easier computation when you have things that abut. E.g. it's [a,b) [b,c) [c,d) rather than [a,b-1] [b,c-1] [c,d-1].

* https://en.wikipedia.org/wiki/Interval_(mathematics)#Includi...

But it seems to be weirder than that, according to the game (can someone explain this to me?):

start:1, end:4 = 1,2,3 (start-inclusive, end-exclusive)

start:5, end:2 = 2,3,4 (I guess this means right-exclusive, whether it's 'start' or 'end'?)

start:1, end:-2 = 1,2,3,4 (the puzzle text says -1 is the first grid-line from the right, i.e. 5, but that doesn't follow, because now it's right-inclusive)

start:-3 = 4 (so -1 is grid count+1, which explains the above?)

I'm with you, this feels very weird to me.

Usually you get a reasonable relationship between zero- and one-indexed views of the same thing. The relationship is normally that the zero-indexed points 0 and 1 form the start and end bounds of the 1st item.

CSS grid numbers columns 1, 2, 3 and also number the the lines around those columns 1,2,3,4. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_La...

Having grid line 1 come before column 1 makes it feel like the grid lines are substantial and the columns are merely the bounds between grid lines.

> Having grid line 1 come before column 1 makes it feel like the grid lines are substantial and the columns are merely the bounds between grid lines.

Correct. And IIRC the spec doesn't even have columns (they're just referenced to help understanding), just column bounds.

Isn't there some presumed universal convention for how to index things, present in the most popular programming languages, that avoid all of these issues that would have really easy to code?

I feel like I'm spending my time doing the wrong things ... I should have been arguing for sensibility during the standards writing. These modern css things are only here to make things easier, not more wonky and strange - we already have that. If they're just dedicated to inventing new bizarreness to replace the older wackiness, where have we actually come?

Maybe designers don't have a culture of counting from 0 like programmers do?

There are programmers who don’t count from zero. And even programmers who count from zero but don’t do so consistantly as soon as they implement even the simplest personal indexation.

Programmers don't count from 0. Its just in many languages it makes sense like in C where an arrays name is actually a pointer to the first element and the index says how many positions to move away from it so foo[0] is the pointer to the first element and then move 0 spaces away.

The tradition of starting at 0 just got carried on to everything because having a standard is better than having to memorize what everything uses

There are good reasons to start counting at 0 beyond convention. Dijkstra wrote a small essay on the topic in 1982 called "Why numbering should start at zero."

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...

As someone that started programming in languages that count from 1, I kind of disagree with that essay.

Specially when dealing with Algol derived languages, where the indexes can be specified in a flexible way.

> why the end column is one more than the position of the column that actually stops

The positions are, I believe, the positions of the grid lines, not the grid columns.

That still seems super unintuitive to me, because the whole thing is ‘grid-column-end’, not ‘grid-column-line-end’.

Between this and how weird the negative syntax operates, I suspect that I would end up using the start/span syntax the most, but my company requires code that supports IE9, so I will probably only touch this on a regular basis in like five years.

I really hate products where the in/out points are not the same inclusiveness. There are several video programs I've used in the past that are similar to this where the in-point is inclusive, but the out point is not. If the in/start designates the first thing I want to include, then I would expect the out/end to also designate the last thing I want to include.

It's just a mild thing to get over, and visual tools like this make it very easy to realize the end is exclusive. However, it is not always so easy in video tools unless the next frame to your out is an obvious change.

There's an extra difficulty with something like video software.

Consider what the expected outcome would be for "isolate from second 1 to second 10". Then the expected outcome for "isolate from frame 1 to frame 10".

What happens with a video at 1fps?

Now we're getting into definitions of "what is 1 second?", and I always reply "a second is a second, regardless of the divisions". Same when syncing audio to video. Straight audio is just a division of sampling rate, so regardless if you record video at 24,25,30, etc, audio recorded at 48kHz is always the same. It only gets confusing when trying to force sync by embedding timecode into the audio or laying the audio to a video format. Now, you're trying to subdivide the audio into video frames, and that's just going to make framerate conversions difficult. My biggest pet peeve with this is all of the MP4 based capture formats where the audio alignment is within +/- frames. I love frame advancing to the clapper in the clapped position, but the audio pop is frame(s) ahead/behind, and sometimes even sub-frames ahead/behind. It's one of the things I miss the most about FCP7. I could option-click the timeline and slip the audio into alignment with the video. Premiere doesn't allow for this, and I refuse to even install FCPX to investigate. I know just make it the audio department's problem ;-) Wow, I just jerked the wheel so hard far left from the actual topic.