What's the difference between ./ and no slash path in html?

Question

What's the difference within this two lines of code?

<img src="./emelf.jpg" alt="Emelf">
<img src="emelf.jpg" alt="Emelf">

I tried to check if they both work when I open my html file with

directly dragging it to browser tab,
opening it with Visual Studio Code "Open with Live Server".

In both cases image opens correctly. So I don't understand what's the difference.

I already read that "./ is the the folder that the working file is in:" My question is not about the meaning of "./". It's about the difference between situations when

there is a slash with one dot,
there is no slash and no dot.

Does this answer your question? [What does "./" (dot slash) refer to in terms of an HTML file path location?](https://stackoverflow.com/questions/7591240/what-does-dot-slash-refer-to-in-terms-of-an-html-file-path-location) — Zaid Aly, Jan 24 '21 at 05:27
@RubenKubalyan it does answer, kindly read the first answer. — OMi Shah, Jan 24 '21 at 05:35
@OMiShah: That question asks about files, but this question seems to be about URIs/IRIs. Unix path resolution and URI/IRI resolution are different. For one, Unix has no concept of scheme, authority, userinfo, username, password, host, port, query, or fragment. — Jörg W Mittag, Jan 24 '21 at 05:45
@JörgWMittag thanks for giving me a direction to think about. I'm not sure but I think you understood my question correctly. — Ruben Kubalyan, Jan 24 '21 at 06:01
@ZaidAly: That question is about *file paths*. This question is about URIs/IRIs. The resolution algorithms are different. In particular, in URI/IRI resolution, there is an edge case (see the last paragraph of RFC 3986 sec. 4.2) that is relevant to the *exact situation* the OP is asking about that does not exist in file path resolution, and is thus nowhere mentioned in the answers to that question. — Jörg W Mittag, Jan 24 '21 at 06:11

score 1 · Answer 1 · answered Jan 24 '21 at 05:37

1

There is no functional difference. As you've seen, both will reference the relative file that you want.

answered Jan 24 '21 at 05:37

Brad

159,648
54
349
530

I just wanted to know is there anything that I don't see? Cause I might think there's no difference and then be disappointed. – Ruben Kubalyan Jan 24 '21 at 05:42
@RubenKubalyan I don't know how much clearer I could be. And, the answer we closed your question in favor of has additional details. Why don't you believe everyone telling you that there is no functional difference? – Brad Jan 24 '21 at 05:42
@RubenKubalyan You don't have to apologize, just trust the documentation or explain why you don't so we can clarify. :-) – Brad Jan 24 '21 at 05:44
The only reason is: why two different ways when it could be done with only one way? I just think that if the creators decided to add two ways to do the nearly same things, it shows that there must be a difference. If it's not, then what's the meaning? That's why for me is a bit difficult to agree with you faster then you expect it from me. – Ruben Kubalyan Jan 24 '21 at 05:48
@RubenKubalyan Thanks for clarifying the question. The relative path convention of `.` and `..` is a holdover from Unix. It's supported on the web out of convenience. I can't think of any time you would need to use `./` on the web, but it isn't hurting anything. – Brad Jan 24 '21 at 05:51
Ahhh... now I think I can say, that my question got it's answer. Thank you! – Ruben Kubalyan Jan 24 '21 at 05:53
1

No problem! Happy to help. – Brad Jan 24 '21 at 05:57
1

@Brad: In `a:b`, `a` is interpreted as a scheme, whereas in `./a:b`, `a:b` is the path segment. So, `foo` and `./foo` are not always equivalent, depending on what characters are present in `foo`. (See RFC 3986 sec. 4.2) – Jörg W Mittag Jan 24 '21 at 06:05
1

@Brad: Your answer is correct for Unix path resolution (which is what the question that this question is closed as a duplicate of is about), but this question is about URI/IRI resolution, which is different from Unix path resolution. – Jörg W Mittag Jan 24 '21 at 06:08
1

@JörgWMittag Please add an answer with your information. – Brad Jan 24 '21 at 06:19
1

@Brad: I was just waiting (and lobbying :-D) for the question to be re-opened. – Jörg W Mittag Jan 24 '21 at 06:27

score 1 · Accepted Answer · edited Oct 07 '21 at 11:21

In your particular example, with those exact URIs, both will resolve to the same URI, but only because of the specific circumstances of your example. In general, the two are not equivalent.

./emelf.jpg is a relative reference, more precisely a relative-path reference with a path consisting of two path segments, . and emelf.jpg.
emelf.jpg is also a relative-path reference with a path consisting of one path segment, emelf.jpg.

If we follow the relative resolution algorithm, we end up with the same absolute target URI for both examples, because of the remove dot segments sub-algorithm, in particular step 2.A. of sub-section 5.2.4 of RFC 3986:

If the input buffer begins with a prefix of "../" or "./", then remove that prefix from the input buffer

However, if the last path segment in the example could be any generic path segment, containing any legal URI character, then it is not always guaranteed that foo and ./foo are equivalent. Specifically, if the path segment contains a colon :, then the two examples are interpreted differently:

./a:b is a relative reference, more precisely a relative-path reference with a path consisting of two path segments, . and a:b. (In other words, it is interpreted the same as in the original example.)
In a:b, a is interpreted as a scheme, and b as the path.

See the ultimate paragraph of section 4.2 of RFC 3986:

A path segment that contains a colon character (e.g., "this:that") cannot be used as the first segment of a relative-path reference, as it would be mistaken for a scheme name. Such a segment must be preceded by a dot-segment (e.g., "./this:that") to make a relative-path reference.

Adding a dot-segment anywhere in a path is always a no-op, but if you remove one, you may change how the URI is parsed. So, if you assemble paths from segments from different sources, and you don't know whether those segments may contain colons, you either need to check whether or not the situation shown above applies and slap an additional dot-segment on the front, or you simply always slap a dot-segment on the front, knowing that it is guaranteed to work.

Note: everything I wrote here applies to IRIs as well. IRIs mainly change the allowed characters, but not the parsing or interpretation.

What's the difference between ./ and no slash path in html?

2 Answers2