Amaya 9.0 beats (easily) Nvu on CSS because of Gecko
By glazou on Thursday 3 February 2005, 17:51 - CSS and style - Permalink
Amaya 9.0 has a wonderful feature. I mean it has a feature I wish we could have in Gecko for Nvu and in fact all Gecko-based applications because it would allow us to finely debug stylesheets. Amaya is able from the computed style of a given property on a given element, to climb the Cascade and retrieve the CSS declaration that eventually triggered, after the whole Cascade's process, that computed value.
You may think it's a geeky feature but it's not. It's a FUNDAMENTAL feature for editing environments: if a given style is created by complex style rules, it's the only way to modify that style without having to use inline style through the STYLE attribute. Example:
#foo .toto { color : red }
p { color: green; font-family: monospace}
div .toto { color: blue; font-family: fantasy }
...
<div id="foo"><p class="toto">this is a paragraph</p></div>
The computed values of 'color' and 'font-family' on the paragraph element are respectively "red" and "fantasy". The rule responsible for the former is the first one; the rule responsible for the latter is the last one. So if you want to change the color of that paragraph without using inline style, and without inserting an important rule of very high specificity to beat all existing rules, you must change the one rule that made the style. Amaya is able to do it. Nvu is not, because we can't reverse the cascade in Gecko. And that's a real pity.
I've said many times both in the Mozilla community and the W3C's CSS WG that this is absolutely needed for editing environments. Without success. So mucho congrats to Irène Vatton and her INRIA team. I hope that we'll be able in the future to have an implemented standard to do that.
Comments
Is there an open bug for this feature?
I just gave Amaya 9.0 a try recently and its user interface has definitely improved. It is the only editor I know of that allows simultaneous editing in structure, rendered, and other views. The closes thing I know of is manipulating the DOM tree in Mozilla with the DOM inspector to see the effect of changing a value without the constant save/reload problem that plagues Web authoring.
Well, at least you can somehow access the list of rules applied to a certain node, and their formatting values, when using DOM Inspector's "CSS Style Rules" pane for an object (instead of "DOM Node" which is the default). Couldn't something be worked out on top of that?
I disagree that Amaya easily beats NVU on CSS. One problem with the Amaya approach, the average person building web pages likely will not have the slightest clue on how to set up style sheet rules and implement them on an element in order to set the css value for an element. The NVU simplified approach allows you to build space separated lists for an elements class value by toggling on and off the classes. In Amaya you have to do this by typing the space separated list. The average user can build simple sets of class style rules in a linked style sheet and easily apply these in NVU. The average user cannot do this in Amaya. For the target audience it is aimed at, the NVU approach is better than the Amaya approach, which is better suited for "power" users.
Example. I have following classes either through a linked css file or style in the header:
.fontfamily {font-family: arial}
.fontcolorred {color: red}
.fontcolorblue {color: blue}
.fontsize12 {font-size: 12pt}
.fontsize14 {font-size: 14pt}
<p class="fontfamily fontcolorred">this is a paragraph</p>
This gives the paragraph the arial font with red text. IN NVU I can change to blue text
<p class="fontfamily fontcolorblue">this is a paragraph</p>
By selecting the element in the element tree at the bottom of the screen, right clicking on the selected element and selecting classes, going to the top and toggling off fontcolorred class and than toggling on fontcolorblue. It's very simple. I would not change NVU's way of doing it for the world. Want to test this? Link to the following style sheet file, commerce.wi.gov/css/outpu... You will see a bunch of classes. Start to toggle on and off the classes and see the styles change.
Having tested both Amaya and NVU in a working environment, at this time I pick NVU.
Gary: so you've tested both... I have coded both... I used to be a member of the technical team who made Grif, an ancestor of Amaya. I worked on the deep layout engine, transformations, document models and DTD parsing/validation, CALS tables and a few other interesting stuff.
To be the best of my knowledge, the underlying native style language of Amaya, P, is __incredibly__ superior to CSS even it is a little bit more complex. The layout engine is weaker *as it is* in terms of reflow quality (but could be improved) but it's certainly easier to extend, and it is MUCH more powerful on positioning, generated content, conditions (think CSS selectors), table handling, and so on.
If you used the inspector APIs, and the rules were ordered by specificity (I don't know if they are or not, we'd have to check and fix it if not), wouldn't this be easy?
Well, could we write a not-so-nice DOM-walking script to collect this information together?
Theoretically, it's possible. document.styleSheets to collect the rules not overridden by HTML style attributes, and then perhaps some code to reconstruct how those rules apply to an element you're trying to debug?
CSS selectors... aka Xpath that sucks.
Daniel, even I've implemented "the reverse of cascade" in our new HTML engine (actually it was there from the very beginning) but I cannot see how it will help practically.
Yes, I cannot determine which rule triggered particular property but it does not help as, generally speaking, I cannot change the attribute.
Let's say we have a rule:
p { margin:0 }
and user will want to change margins for only one given paragraph. Are you going to change this rule? What will happened with other Ps then?
I even can say how many elements in the DOM are using this particular attribute value but this also will not help you too much. Applying complex rules and spreading their values across the whole system of loaded CSS (sic!) behind the scene will make WYSIWYG editing even more look like as a "telling fortunes" business.
IMHO:
As I already posted on www-style@w3c.org, WYSIWYG editor should use different ("flat") DOM to be a practical solution for human.
I would add to WYSIWYG letters couple more: "... You Get and You Can Change Predictably".
See, all WYSIWYG word processors have DOM specificly designed for visual editing. HTML, XHTML, CSS and friends have lost ability to support consistent/noncontradictory WYSIWYG editing after HTML 3.2. Probably we don't want but we shall admit this.
My IMHO as usual.
Andrew Fedoniouk.
Doesn't the Web Developer extension (www.chrispederick.com/wor... provide at least an approximation of that ?
for instance, the output for the document in your example is:
Style Information - file:///D:/tests/testdg.html
file:///D:/tests/testdg.html
p (line 3)
{
color: green;
font-family: monospace;
}
div .toto (line 4)
{
color: blue;
font-family: fantasy;
}
#foo .toto (line 2)
{
color: red;
}
So you have the rules in increasing specificity order.
So are you saying I shouldn't bother downloading the latest version of Nvu and just switch to Amaya instead?