This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
1. Create a project from the Ember.js Trek Tutorial sample 2. On line 14 of index.html, delete "?v=2" from the link to the style.css file to avoid effects of bug 223858 3. Run it and enable select mode in browser 4. Select one of the names in the committers list in the page 5. In the IDE's CSS Styles window, select font-size property, note that in Applied Styles the second item is highlighted (style.css:14) 6. Change font-size to e.g. 30pt => Nothing is changes in the running page (not even after refreshing the browser) On the other hand, when I add "font-size: 30pt" to rule "a, a:active, a:visited" on line 78, it is applied.
I think it is being overridden by font property and it is "mistake" in the rule. The first defined property is font-size and then font so it imho overrides previously declared font-size. If you change order of these properties in the rule, it works.
Thanks for the analysis, you are right. So what should the IDE do about this? Should the IDE try to change the order of the properties to "fix" the rule? Or alert the user by a warning? Or just ignore it and do nothing? Secondly, how often do you think this problem will occur? If this is not very frequent, then this is not a P2 and feel free to downgrade to P3. Cc'ing also Marek.
vriha is right that the rule that contains the font-size property doesn't make sense (i.e. is incorrect). Hence, it is correct that the running page doesn't change when the value of the property is modified. So, the only defect that I can see is that the font-size property is not identified as being overridden. If it was marked as overridden (i.e. if it was crossed out in the Rule Editor) then it would be clear immediately why it doesn't affect the selected element. Unfortunately, the 'font-size' property is not overridden by another 'font-size' property but by a shorthand property 'font'. The page inspection doesn't have any hard-coded mapping between short- and long-hand names. It obtains all the needed data through the WebKit Remote Debugging Protocol. Unfortunately, the data provided in this case are not sufficient to find out that the 'font-size' property is overridden by the 'font' property. You can verify that in Google Chrome - it also (incorrectly) doesn't mark this 'font-size' property as being overridden. Hence, I am closing this issue as will not fix.
I think the shorthand typically resets all the individual to defaults so a simple shorthand -> individual mapping would help bit and shouldn't be hard to create. Then also the editor could utilize such info and provide a warning which would say: "font-size is overridden" for such code: div { font-size: 10px; font: arial; }