Issue summary updated: #13
Problem/Motivation
HTML 'class' attribute can be used not only for presentational, but also for semantic purposes [note: Drupal core only uses class attribute for CSS styling], yet Drupal code base contains multiple references to 'CSS class'.
Beta phase evaluation
Issue category | Task (it might maybe be a bug if we can say the documentation is *wrong* to call it a CSS class) |
---|---|
Unfrozen changes | Unfrozen because it only changes documentation. |
Proposed resolution
Replaces occurrences of 'CSS class' with 'HTML class attribute'
Remaining tasks
- Find if there are translatable strings containing 'CSS class'
- Write patch
- Review patch
User interface changes
Probable change in translatable messages (to be confirmed)
API changes
Probable change in functions/methods comments, no change in API itself.
Original report by @loominade
the class-attribute not exclusively meant for CSS. Its also useful for javascript and various html parsers. If I were to recommend a term for this I would choose 'Element class'.
Comment | File | Size | Author |
---|---|---|---|
#9 | drupal-avoid_term_css_class-1723446-9.patch | 15.85 KB | yannickoo |
#7 | drupal-avoid_term_css_class-1723446-7.patch | 14.55 KB | yannickoo |
#5 | Screen Shot 2012-08-13 at 11.12.21.png | 54.16 KB | yannickoo |
#3 | drupal-avoid_term_css_class-1723446-3.patch | 15.8 KB | yannickoo |
Comments
Comment #1
ygerasimov CreditAttribution: ygerasimov commentedI have done search in the core and views module for word 'CSS class' and see about 60 matches. So it looks like it is the way element class is named. So it is better to keep views aligned with same terminology as the core so we don't name same thing differently.
Comment #2
loominade CreditAttribution: loominade commentedor we first move this issue to the drupal core
Comment #3
yannickooComment #5
yannickooThe patch failed because a comment was not found, strange.
Comment #6
yannickoo#3: drupal-avoid_term_css_class-1723446-3.patch queued for re-testing.
Comment #7
yannickooI removed the jquery.ui.datepicker part because that's part of jQuery UI and not Drupal I think.
Comment #9
yannickooI manually reviewed the patch and customized it. I also removed the part where the whitespaces was removed from theme.inc. Will put this into another issue.
Comment #10
yannickooComment #11
YesCT CreditAttribution: YesCT commented#1727796: Rename "CSS class" to "element class" was created for views because of this issue.
Comment #12
hass CreditAttribution: hass commentedThat sounds pretty strange to me. The attribute class is for CSS only. Only that JS uses a CSS selector (class) to find an element don't make this wording wrong. Element class sound not intuitive to me. I tend to say won't fix.
Comment #13
valthebaldClass attribute is definitely not for CSS only (as mentioned above).
From wikipedia (http://en.wikipedia.org/wiki/HTML_attribute):
We are going to work on this issue during DC Wroclaw 2014
Comment #14
valthebaldComment #17
TravelTechie CreditAttribution: TravelTechie commentedI'm looking this as a good chance to apply my first patch as a re-roll since it's tagged Novice and not assigned to anyone. I see that it is also tied to #1727796: Rename "CSS class" to "element class" issue that hasn't been resolved and is tagged for dcwroc2014.
Does this mean it's already considered assigned and should not be touched or that the Views issue needs to be resolved before any work is done?
Comment #18
YesCT CreditAttribution: YesCT commentedI dont think this needs to wait on #1727796: Rename "CSS class" to "element class". That issue is about user facing strings in the UI and this one is about code documentation (comments).
--
I do think it needs https://www.drupal.org/contributor-tasks/update-allowed-beta needs to be done to evaluate it for
https://www.drupal.org/contribute/core/beta-changes
It is a normal task (not a critical or major, and not a bug or feature request).
It might be allowed since it is only changing one of the unfrozen areas: documentation.
I'm not 100% on that though.
Comment #19
yannickoo(I think "HTML class" would be more clear than "Element class")
Comment #20
valthebaldMaybe "HTML class attribute"? No pressure though...
Comment #21
yannickooA "HTML class" cannot be sth. different than the attribute, what do you think?
Comment #22
valthebaldIt cannot indeed. I just thought that the term 'class' is too overloaded. But once again, I do not insist and agree with just 'HTML class', not 'HTML class attribute'
Comment #23
yannickooAnother point for "HTML class" – Imagine you want to name a variable with that class value in it:
$html_class_attribute
is definitely not better than a quick$html_class
:)Comment #24
JohnAlbinTLDR; Drupal core only uses class attributes for styling, so the phrase "css class" is clear and concise.
HTML5 tags are used to classify your content. That's where HTML semantics lives: the tag itself. There's no such thing as taxonomy for HTML elements. If you write
<article class="event">
, it does not classify the type of article as an "event"; it means please add the "event" _design_ to that article element.JavaScript best practice no longer uses classes; it uses data attributes.
microformats is the only thing I am aware of that uses CSS classes for content semantics. And it is a total hack. They came about before data attributes, but they refuse to use them now because they claim that they are only for _private_ developer use and not for _public_, shared developer use. Lame.
"element class" is technically correct, but so vague that it is confusing. I've never heard of "element classes". "html class" is wrong because Drupal can also output RSS, XML, etc. And, in D8, potentially output SVG, MathXML, etc.
"CSS class" is clear, even if you are entering a microformat class.
The https://developers.whatwg.org/content-models.html#classes HTML5 spec refers to them using a few different phrases:
getElementsByClassName()
) - Slightly vague. In the context of a Drupal form, it doesn't immediately bring up the idea of CSS styling.Comment #25
JohnAlbinLastly, since Drupal core only uses class attributes for styling, its forms should use "CSS class". A micoformat contrib module could use Forms API to change that text to the unambiguous "CSS class or microformat". Though, actually, since micoformat classes and CSS classes are different things, it should really provide a different form widget for microformats and then merge them together into $classes in the background.