Closed (outdated)
Project:
Seven
Version:
1.0.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
3 Oct 2014 at 14:15 UTC
Updated:
16 Jun 2025 at 12:11 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
roblav commentedComment #2
roblav commentedComment #3
lewisnymanOk, here's a patch. It's pretty cool to have these documented in a living style guide. It exposes a lot that would get ignored otherwise.
Comment #4
lewisnymanComment #5
jhodgdonThis file should start with an @file doc block.
This patch seems also very unmaintainable, if you have to do things like
If someone adds a new element and it logically goes between 1.1.1 and 1.1.2, you would have to renumber everything. Is this really necessary?
Comment #6
tadityar commentedPostponed until things have been decided in #2293627: [meta] Document Human Interface Guidelines
Comment #7
jhodgdonComment #8
lewisnymanComment #9
lewisnymanThis needs a reroll and a change from the feedback in #5:
The maintainability of the styleguide: x.y.z has been discussed in #2404111: [Meta] Create a visual style guide for the Seven theme. It's the current limitation of the solution, let's leave them as is now.
Comment #10
tadityar commentedIs the @file docblock correct? There was one conflict and I used the one from the patch because it seems more consistent with other blocks.
Comment #11
lewisnymanI think it's worth mentioning in a comment that here is a reuseable .link class that can be use to make any element look like a link.
Can we move this comment about the heading classes into the new comment?
This comments is too long and goes off the 80 character width. It's also maybe too hipster for Drupal core :P Shall we just latin like in http://getbootstrap.com/css/#type-body-copy ?
I have also added a styleguide task to https://github.com/lewisnyman/drupalcore-frontend-toolkit. If you follow the instructions you can use it to check that your work is being parsed by KSS correctly.
Comment #12
lewisnymanMade the changes above with a few other improvements.
Comment #13
jhodgdonUm, why are you using this type of syntax in the comments? This goes against all of our guidelines and standards for documentation:
Comment #14
lewisnyman@jhodgdon That's the syntax that KSS parses, I don't think that it's possible to add *s in on every line because KSS interprets them as markdown lists, see the example docs: http://warpspire.com/kss/syntax/
Comment #15
jhodgdonThat is extremely totally utterly lame. I wonder if we should rethink this. Probably should discuss on the parent issue, which did not really I think come to a conclusion that this was a good thing to do, given that the comments are weird, don't comply with our other comment standards, and don't stand out well in the file as comments like other comments would.
Comment #16
lewisnymanThese are flimsy reasons, considering that the PHP comment standards are inherited from Doxygen, a common standard for backend code documentation. To hold frontend code to the same standards as backend instead of embracing on a common standard for frontend code documentation feels overly conservative and not-invented-here.
If you have any alternative suggestions I'd love to hear it, help find me an implementation of Doxygen for CSS, because I couldn't. I'm getting tired of this going nowhere.
Comment #17
jhodgdonI replied to this comment on the parent issue -- let's continue the discussion there, and meanwhile I think all these issues should not have been un-postponed.
Comment #18
lewisnymanComment #30
longwaveComment #31
avpadernoComment #32
avpaderno