nested styles refer to top-level parent in sourcemap line number

[opeologist]

i'm having an issue where my nested styles' sourcemap line number in chrome is referencing the top-most parent selector line and not the line that the nested selector starts.

body {
  h1 {
    background: #f00;
  }
}

will show file.scss:1 instead of file.scss:2 for the h1

i've tried outputting the map file to a separate file and embedding it, all the same.

using 3.4.0-beta1

[xzyfer]

Hi @tehOPEologist, thanks for this issue. @mgreter any thoughts on this one?

[mgreter]

Looks ok to me ...

[opeologist]

hm, this isn't what's happening for me =/ here's what mine is doing: http://imgur.com/a/WiABA

[mgreter]

Why is Body on line 5 in your screenshot??

[opeologist]

i just added some sample code in an already existing file. the devtools image shows core.scss:5, the parent of the h1, instead of 6, where the h1 selector starts.

[opeologist]

@mgreter am i not understanding how the sourcemapping is supposed to work? if it's working as intended, then ok, but i had someone online say their node-sass was showing the nested line number instead of the nested selector's parent line number =/

[opeologist]

@xzyfer any update?

[xzyfer]

Not really looking into this at the moment. Have you tried te beta?
On 24 Oct 2015 5:30 am, "Aaron Giordano-Barry" notifications@github.com
wrote:

@xzfer any update?

—
Reply to this email directly or view it on GitHub
#1206 (comment).

[opeologist]

didn't see there was a new beta. i'll try that and report back. thanks!

[mgreter]

@tehOPEologist @xzyfer I dont see anything wrong with what libsass produces for the given input!

http://libsass.ocbnet.ch/srcmap/#Ym9keSB7CiAgaDEgewogICAgYmFja2dyb3VuZDogI2YwMDsKICB9Cn0=

[opeologist]

looks like latest node-sass beta is doing the same thing as before. @mgreter i was under the impression that the sourcemapping would show the line of the actual selector, not its topmost parent. is showing the line number for the topmost parent of the tag the intended result? like i said when i first opened this issue, i've seen nested style with sourcemapping show the line of the actual selector, not its topmost parent..

[opeologist]

just ran a test with the latest ruby sass and it's sourcemapping nested children on the child's line and not the top-most parent like it should be. this is definitely a bug and isn't working as intended.

Ruby Sass 3.4.19:

body {
  h1 {
    background: red;
  }
}

compiles to:

body h1 {
  background: red; }

/*# sourceMappingURL=core.css.map */

core.css.map:

{
"version": 3,
"mappings": "AACE,OAAG;EACD,UAAU,EAAE,GAAG",
"sources": ["core.scss"],
"names": [],
"file": "core.css"
}

---

node-sass 3.4.1:

body {
  h1 {
    background: red;
  }
}

compiles to:

body h1 {
  background: red; }

/*# sourceMappingURL=core.css.map */

core.css.map:

{
    "version": 3,
    "file": "core.css",
    "sources": [
        "core.scss"
    ],
    "mappings": "AAAA,IAAI,CACF,EAAE,CAAC;EACD,UAAU,EAAE,GAAI,GACjB",
    "names": []
}

[opeologist]

@mgreter do you see what i mean now with those examples?

[opeologist]

@xzyfer any thoughts? trying to figure out if this is a libsass issue and i should open an issue on their repo or if this is node-sass specific... definitely an issue that needs addressing!

[chriseppstein]

Ruby Sass generates different source mappings for that input: "AACE,OAAG;EACD,UAAU,EAAE,IAAI"

[opeologist]

@chriseppstein yes, and it seems like Ruby Sass is generating the correct mappings whereas libsass/node-sass is generating only the top-most parent of the selector

[opeologist]

@mgreter any ideas as to why this is happening? i just want to know if this is intended or not, as the sourcemap is visibly different than ruby sass

[jenwachter]

Just wanted to add that I am also having the exact same issue.

[opeologist]

@jenwachter ok cool, i'm glad i'm not the only one experiencing this. hopefully we can get some eyes on this and get it resolved asap!

[HugoHeneault]

I'm facing this issue too. It's quite hard to work with lots of nested selectors... :'(

[opeologist]

gonna close this for now, since it seems to be an issue with how the browsers are interpreting the srcmaps. please reference this for a temporary way to get the lines of the styles: sass/libsass#1747

[xzyfer]

Although I agree with @mgreter that we're likely technically correct, the fact that we differ from Ruby Sass in this is a enough to provide a fix.

[mgreter]

@xzyfer ruby sass sourcemaps are lacking a lot according to previous discussions with @am11. I decided to do better than that and therefore libsass has much more detailed source-maps than ruby sass does (not sure if this is still true, since those discussion are over a year old). The question is really if we want to merge the crutch in #1759 into master or not. That change is techically not correct, but will make chrome and firefox report a more usefull mapping. But it could confuse more advanced tools, since that mapping is technically not correct.

[xzyfer]

The question is really if we want to merge the crutch in #1759 into master or not

Yep I agree. On it's merits alone merging that fix is kinda sucky, but I think we should (see below).

That change is techically not correct, but will make chrome and firefox report a more usefull mapping

This is my concern. LibSass feels broken to users which IMO is the important concern

it could confuse more advanced tools, since that mapping is technically not correct

As you previously mentioned these tools don't yet exist. Until someone reports an issue in regard to this I think it's more important to match user expectations.

[mgreter]

OK, so this bascially means you're in favor of merging sass/libsass#1759 into master. Although it's technically not correct, it will satisfy the main consumers (aka browsers) of our sourcemaps. If so please feel free to hit the merge button on that PR!

[xzyfer]

This has been fixed in LibSass. I'll close this issue when we do a new release with the update LibSass version.

[opeologist]

thank you so much all! i'll be patiently waiting for the new node-sass release! :D

[HugoHeneault]

Awesome! Can't wait for it!!

[ericwooley]

Any updates on this?

[tomlagier]

Any updates on this?

[opeologist]

just tested on node-sass v3.5.0-beta.1 and confirm sourcemap line numbers are referring to correct selector! thank you SO MUCH @mgreter !!!!! i'll leave this to be closed by you once the version goes out of beta.

[mgreter]

Even though it is technically wrong what I did to achieve this (since browsers interpret it not carefully enough IMO), you're welcome 😄

[opeologist]

xD thanks again man!

[am11]

Was this problem occurring only on Chrome or every browser tools with source-map support? Last time I checked (few months ago, while giving a presentation), my sample worked on Chrome, Edge (MSDN) and Firefox (Mozilla hacks). If there is a disparity between what libsass was generating previously and how Chrome is interpreting it, with this fix, it might have broken other browsers. :/
LibSass emits detailed mappings, which many trans-compilers (of JS and CSS) lack including RubySass. @mgreter has nailed this feature! 👍

@mgreter, note that what I used in WebEssentials2013 for VS-IDE preview window was based on https://github.com/mozilla/source-map (which is probably used in Firefox tools implementation as well), so it might interpret the line numbers differently. Last I remember, line and col number were off by one (line was 0-based and col was 1-based or vice versa), viz the typical:

there are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

Thank you so very much nonetheless. 😎

[mgreter]

@am11 these links might be of interest:

• less issue about same thing (Wrong line-numbers on source-map selectors - chrome reports position of first element, not last element less/less.js#1492)
• chrome bug: https://code.google.com/p/chromium/issues/detail?id=287382

[ggedde]

I am still having this issue on FIrefox.
There is another open issue for this that might clarify why this is happening: #2092

[SweetsXob]

This problem does not seem to be solved now.
It seems less doesn't have this problem