命名Dom元素Id属性的最佳实践

发布于 2024-07-21 03:05:15 字数 737 浏览 7 评论 0原文

这与 DOM 元素的 id 属性的命名约定有关,我猜也与 name 属性有关。 当谈到 JavaScript 时,根据我的理解和所做的,除了类名之外,总是使用驼峰式大小写。 类采用 Pascal 大小写。

话虽如此,我主要在 ASP.NET 中进行开发,这就是我遇到 id 属性命名问题的地方。 在 ASP.NET 中,如果将新的服务器控件拖放到页面上(我很少这样做,我是一个喜欢标记的人),默认名称始终采用 Pascal 大小写,因为它们需要符合 .NET 框架服务器端代码的命名指南。

因此,当涉及到命名 ASP.NET 服务器控件的 id 属性或标记中的元素时,我遵循驼峰式命名 id 属性的规则(Javascript 命名准则),但这与 .NET 命名准则相冲突。

那么,第一,你们通常对 DOM 元素中的 id 属性使用什么大小写;第二,在 ASP.NET 中开发的 .NET 人员如何命名 id 属性?

最重要的是,当我在标记中创建表单元素时,我通常使用匈牙利表示法进行文本输入,例如

<input type="text" id="txtUserName" />

或 等复选框,

<input type="checkbox" id="chkSelectAll" />

这绝对违反了 .NET 服务器端代码命名准则,也可能违反了 JavaScript 准则。

非常感谢任何建议。

This is related to naming conventions for a DOM element's id attribute and I guess the name attribute as well. When it comes to JavaScript, from what I understand and have done is always use camel case except for the names of classes. Classes are Pascal cased.

Having said that I develop in ASP.NET mainly and here's where I run into a naming issue for the id attribute. In ASP.NET if you drag and drop a new server control to a page(which I rarely do, I'm a type the markup kinda guy), the default names are always Pascal cased because they need to conform to the .NET framework naming guidelines for server-side code.

So when it comes to naming the id attribute of ASP.NET server controls or just elements in markup, I follow the rule to camel case the id attribute (Javascript naming guidelines), but this conflicts with the .NET naming guidelines.

So, one, what casing do you folks normally do for the id attribute in DOM elements and two what do the .NET folks who develop in ASP.NET do for naming the id attribute?

On top of that when I'm creating form elements in markup, I generally use Hungarian notation for text inputs, like

<input type="text" id="txtUserName" />

or for checkboxes like

<input type="checkbox" id="chkSelectAll" />

Which definitely goes against .NET server-side code naming guidelines and maybe JavaScript guidelines as well.

Any advice is much appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

我恋#小黄人 2024-07-28 03:05:15
  • 保持语义。 使用完整、简单的(最好是英语)单词。 不要试图想出一些奇特或技术性的东西,也不要描述它是什么 - 我们知道这一点。 描述它的作用。。 描述目的会增加信息价值。

  • 不要缩写任何东西! BW_RCB01_SW 对于几年前制作 CSS 的团队来说意味着一些东西,但现在对我来说没有任何意义,我必须向后工作来尝试翻译 BW_RCB01_SW符合我的目的,要么记住该翻译,要么将其记录在某处。 更好的? blackwhite-boxtype1-bottomleft。 它更长,但也不需要罗塞塔石碑。

  • 全部小写并使用下划线或连字符。 我更喜欢连字符,但这完全是一种偏好。 使用连字符应该没有任何障碍,因为它们在 CSS 或 HTML 中没有保留,并且 ID 在所有其他语言中都被视为文字字符串。 小写都是经验 - 浪费了太多时间想知道为什么这种风格不适用哦。 pageContainerLeftpageContainerleft 不同。

  • 准确地识别该元素是什么,但仅此而已。 认真考虑您在名称中嵌入的每条信息以及它是否必要。 在您的示例中 - 您需要知道它是 ID 的复选框吗? 不太可能。 您已经知道您所指的元素是什么,因为它是唯一的 ID,并且无论如何您都必须针对该元素进行编码。

  • Keep it semantic. Use complete, simple, (preferably English) words. Don't try to come up with something fancy or technical, and don't describe what it is - we know that. Describe what it does. Describing purpose adds informational value.

  • Don't abbreviate anything! BW_RCB01_SW meant something to the team who did our CSS to years ago, but it doesn't mean anything to me now and I have to work backwards to try to translate what BW_RCB01_SW corresponds to for my purposes, and either remember that translation or document it somewhere. Better? blackwhite-boxtype1-bottomleft. It's longer but also doesn't require a Rosetta stone.

  • Keep it all lower-case and use underscores or hyphens. I prefer hyphens, but that's totally a preference. There should be no impediment to using hyphens, since they are not reserved in CSS or HTML and IDs are treated as literal strings in every other language. Lower case is all experience - too many hours wasted wondering why the heck won't this style apply oh. pageContainerLeft is not the same as pageContainerleft.

  • Identify exactly what that element is, but no more. Think seriously about each piece of information you're embedding in the name and whether it's necessary. In your example - do you need to know it's a checkbox by the ID? Unlikely. You already know what element you're referring to because it's a unique ID and you have to code against that element anyway.

年华零落成诗 2024-07-28 03:05:15

命名尽可能少的对象肯定有助于保持事物的整洁。 如果您可以通过命名父母并仅提及孩子,那就更好了(在我看来)。 您将获得在每个页面上呈现给客户端的 html 稍微减少的好处。

因为当我确实必须命名元素时,我更喜欢全部小写,并带有下划线符号。 我以前曾因为没有在 CSS 文件中正确处理我的情况而被欺骗,所以如果我能尽早将其视为一个问题,那就是一种解脱。

下划线是字符,而破折号可以解释为减号,因此这是另一个潜在的问题 - 仅坚持使用下划线是有意义的。 例如,Flex 不接受带有用破折号命名的属性的 XML(我知道这些是值而不是属性;但仍然是一个安全的选择)。

我同意上面的观点——没有元素类型或定位或颜色作为类/id。 匈牙利表示法==不好。 对于确定什么是 ID 非常有用。 我喜欢以对象特定的方式命名表单字段 - user_login、user_email、user_address_state_id、user_address_country_id 等,可能都会显示在用户注册表单上。 通常非表单字段的长度不足以容纳下划线,否则您可能可以重命名它们。

Naming as few objects as possible definitely helps keep things clean. If you can get by naming the parent and just referring to the child, that's going to be better (in my opinion). You get the bonus of slightly less html rendered to the client on each page.

For when I do have to name elements though, I prefer all lowercase, with underscore notation. I've been tricked up by not getting my case right in CSS files before, so if I can count that out as a problem early, that's as relief.

Underscores are characters while dashes can be interpreted as minus's, so that's one more potential problem - makes sense to stick with underscores only. Flex, for instance, doesn't accept XML with attributes named with dashes (i know these are values not attributes; but still a safe bet).

I agree with above though -- no element types or positioning or color as a class/id. Hungarian notation == bad. Very useful to determine what's an ID. I like naming form fields in a object specific ways - user_login, user_email, user_address_state_id, user_address_country_id etc, might all show up on a user registration form. Usually non-form fields aren't long enough for underscores, otherwise you might be able to rename them.

拔了角的鹿 2024-07-28 03:05:15

我上一份工作中的一位 HTML 专家实际上建议用破折号来分隔多单词 ID,

<input type="text" id="user-name" />

我很难记住为什么 - 我无法再访问这些内部标准文档。 不过,我知道这确实不能回答您关于 Pascal 与 Camel 外壳的问题。

我个人建议不要使用 HN - 我发现这是一种非常令人厌恶的做法。 如果您需要将复选框数组更改为选择元素,会发生什么情况? 现在,元素的 ID 已内置错误语义。 在我看来,这不值得这么麻烦。

One of the HTML gurus at my last job actually recommended delimiting multi-word IDs with dashes

<input type="text" id="user-name" />

I'm struggling to remember why - I don't have access to those internal standards documents anymore. I know that really doesn't answer your question about Pascal vs Camel casing, though.

I'd personally advise against using HN - I find it to be a largely abhorrent practice. What happens if you need to change your checkbox array to a select element instead? Now the element's ID has false semantics baked-in. It's just not worth the hassle, IMO.

国际总奸 2024-07-28 03:05:15

不管你信不信,但在使用某些 javascript 库时,我在使用连字符作为 id 名称和 css 类名称时遇到了问题。 这种情况非常罕见,但您显然想避免这样的事情。 因此,我使用驼峰式大小写或下划线。 您也可以使用下划线。

否则,一般规则是具有易于阅读和理解的有意义的名称。 当谈到“控件”时,请确保遵循某种命名约定。 就我个人而言,我更喜欢后缀而不是前缀(即 nameText 而不是 textName),但我尽量避免使用后缀,因为我发现它们太冗长了。

所以:
1.有意义的名字。
2. 避免使用后/前缀。
3. 避免缩写(即使用地址而不是地址)。
4.慢慢来。

Believe it or not, but I've had problems with hyphens as names of id's and css class names when using certain javascript libraries. This is very rare, but you obviously want to avoid something like this. Because of this I use camel case or underscores. You can use underscores as well.

Otherwise the general rule is to have meaningful names that are easily read and understood. When it comes to "controls" make sure you follow some sort of a naming convention. Personally i prefer postfixes over prefixes (i.e. nameText instead of textName) but I try to avoid postfixes as I find them too verbose.

So:
1. Meaningful names.
2. Avoid post-/prefix.
3. Avoid abbreviations (ie. address instead of addr).
4. Take your time.

权谋诡计 2024-07-28 03:05:15

根据 mozilla(dom 的最佳来源)的说法,最佳做法是使用字母字符并使用连字符(如果超过一个单词)。

尽管让您的 ID 具有一定程度的人类可读性对于代码理解可能很有用,例如考虑“ticket-18659”与“r45tgfe-freds&$@”

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id

According to mozilla (best source for dom), best practice would be using alphabetic characters and using hyphens (if more than one word).

although having your IDs somewhat human-readable can be useful for code comprehension, e.g. consider "ticket-18659" versus "r45tgfe-freds&$@"

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id

野鹿林 2024-07-28 03:05:15

以下是一些命名指南,它们帮助我解决了 DOM 中的 id 和类问题:

  • 不要在名称中包含类型(即,没有 txt 或 chk)。 我可以使用 CSS 或 jQuery 来选择该信息,更具描述性地
  • 使用下划线作为名称中的分隔符。 连字符在其他语言中并不总是有效,并且驼峰式大小写在标记中有点难以阅读

Here are some naming guidelines that have helped me out with my ids and classes in the DOM:

  • don't include the type in the name (ie, no txt or chk). I can select that info using CSS or jQuery much more descriptivlely
  • use underscores as separators in the name. Hyphens don't always work out in other languages, and camel casing is a little tough to read in markup
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文