Question

我编写了一个非常复杂的小部件，它使用OnDemandList创建一个小部件，允许对商店进行完全编辑（包括添加）。

现在......我不是一个CSS大师（恰恰相反），并且会喜欢一些指导，只是为了检查我是一个半合理的做事。

当我在我的小部件中创建编辑器时，我会这样做：

buildRendering: function(){ 
    // ... 
    this.domNode = put( 'div' ); 
    // ... 
},   

postCreate: function(){ 
  // ... 
  // This is here, because if I set the class in buildRendering, it gets zapped by className (the widget's declaration) 
  put( this.domNode, '.editable-list' ); 
    // ... 
},

然后动态添加编辑器：

    put( row.element, editingWidget.domNode ); 
    put( editingWidget.domNode, '.editable-list-row-editor' );

我也需要以确保每一行都有位置：绝对，以便编辑器放在正确的位置：

    domStyle.set( row.element, 'position', 'relative' );

在CSS中，我有：

.editable-list-row-editor { 
  position: absolute; 
  top: 0; 
  z-index: 20;
}

问题：

1）在最佳实践方面是否可以添加像domStyle.set( row.element, 'position', 'relative' );那样的样式...？或者我应该用CSS做到这一点？我是以编程方式完成的，因为真的非常重要，它是relative。

2）在CSS方面是否可以保留尽可能不具体的内容？这个想法是用户可能（并且可能会）最终编写自己的CSS，并通过编写更具体的规则来覆盖事物......是吗？或者也许我应该写：

.editable-list .editable-list-row-editor { 
  position: absolute; 
  top: 0; 
  z-index: 20; 
}

或更好：

.editable-list .row-editor { 
  position: absolute; 
  top: 0; 
  z-index: 20; 
}

...？

3）从我所看到的，小部件的CSS类应该在postCreate而不是buildRendering中设置，否则Dojo似乎使用className来消除那里设置的任何内容。 ..是你通常用创建自己的domNode的小部件做的吗？

Answer 1

我对内联CSS与CSS样式表的个人看法是，我喜欢在单独的样式表中编写所有内容。这背后的原因是您的代码变得混乱了样式代码，但在分离问题时，我认为最好将CSS写在一个单独的文件中。

当然，内联CSS总是最具体的（最重要的一个），所以如果你真的想强制执行某些东西，你可以在你的CSS规则中添加!important，我建议不要使用它们那么多。

你应该尽可能地编写你的CSS，因为你不想干扰其他小部件/ HTML，但你也不希望相反（外部CSS干扰你的小部件）。但当然，你可以把事情写成：

.editable-list .row-editor {
    position: absolute;
    top: 0;
    z-index: 20;
}

这主要取决于.row-editor实际意味着什么。如果它是“全局”的，您可以保留.row-editor，因为它可以让您定义包含共同CSS的全局.row-editor，而您的.editable-list .row-editor将包含特定的该小部件的CSS规则。

例如，让我们考虑您有另一个具有类似CSS的小部件：

.other-widget .row-editor {
    position: absolute;
    top: 0;
    z-index: 25;
}

然后你也可以写下面的CSS：

.row-editor {
    position: absolute;
    top: 0;
}

.editable-list .row-editor {
    z-index: 20;
}

.other-widget .row-editor {
    z-index: 25;
}

但实际上这取决于你如何看待.row-editor类，如果你认为它只针对你的可编辑列表，那么你也可以考虑为它添加前缀。它与Dojo已经做的类似，Dojo具有全局CSS类，如.dijitInline，但也有特定的CSS类，如.dijitCalendarDateLabel。

如果有人想要更改窗口小部件的样式，他可以添加父类，这样他就可以创建更具体的CSS选择器。举个例子，假设以下是你的CSS：

.editable-list .row-editor {
    position: absolute;
    top: 0;
    z-index: 20;
}

然后，想要更改CSS的人只会向父级添加标记（例如<body>标记）：

<body class="myTheme">
    <!-- Your HTML -->
</body>

然后指定以下CSS：

.myTheme .editable-list .row-editor {
    z-index: 30;
}

这实际上会覆盖您的z-index。 Dojo已经将这个原则与他们的主题一起使用。如果要使用特定主题，可以添加主题CSS并将主题名称添加为正文中的类名，例如：

<body class="claro">
    <!-- Your HTML -->
</body>

当然，您不需要在body级别定义它，只要它是您的小部件的父节点就可以工作。

关于buildRendering vs postCreate的问题，我想您使用的是dijit/_TemplatedMixin mixin。如果是这样，那么如果你看code并寻找buildRendering，你会发现它正在做的事情。这意味着如果您编写自己的buildRendering，您实际上将用您的代码替换它们。如果要确保Dojo首先执行自己的逻辑，则必须编写类似：

的内容

buildRendering: function() {
    this.inherited(arguments);
    /** Your code */
}

额外的代码行实际上会调用继承的modules / mixins的相同方法。你可以用你想要的那一行，如果你不想要调用继承的模块，你可以把它留下来（可能还要破坏它），如果你想在最后一步执行它你只需要切换{ {1}}到this.inherited(arguments);函数的最后一步（但它可能会覆盖您的更改）。

但最后，这只是一个意见，我确信那里有其他意见也是正确的（对于其他甚至类似的用例）。但我可以告诉你，Dojo以类似的方式为自己的小部件做事情，所以也许这也不是一个不好的方法来跟随它。

很抱歉答案很长，但我写了这篇文章，这样对于类似的问题也可能有用。

CSS类和小部件：三个问题

1 个答案: