There is considerable dispute about when questions about code should be closed. As far as I can see, this mostly applies to questions about HTML, CSS, or similar and not to questions about scripting graphic-design tools (correct me if I am wrong). Obviously it would be good to establish some clear guidelines for this and hence I am asking:

What is a good criterion (or set of criteria) for which code questions should be closed?

Answering and voting

  • Suggest one criterion (or set of criteria) per answer. Ideally, an answer comprises all relevant cases.

  • As I consider this a problem of previous discussions on this topic: Please try not to rely on examples too much. There is nothing wrong with using examples for the purpose of illustration of a criterion, but defining via examples is problematic: It leaves room for interpretation and requires that everybody is familiar with the example’s context and understands why you evaluate the example the way you do.

  • Indicate agreement and disagreement on answers by voting.

Food for thought

  • Could we base a criterion on whether the task in question can also be performed with “classical” design software?

  • Would it be reasonable to categorically exclude implementing interactive or conditional aspects, such as, user interactions or querying the platform, a database, or forms?

  • What kind of questions actually lead to problems as collected here? The main issue will probably be that we cannot evaluate answers to such questions.

  • Is it a reasonable to ban questions that ask for help with producing valid HTML, CSS, or whatever?

  • There is no rule that questions cannot be on-topic on multiple sites in the Stack Exchange network.

Previous discussions

2 Answers 2


Suggestion: Disregard the fact that a question uses code when deciding if it is on- or off-topic.

HTML & CSS are tools, just like Illustrator or Photoshop or a pencil and paper.

On a basic level, I do exactly the same thing in Illustrator or InDesign or on paper with pencil that I do in code with HTML & CSS. I also see no fundamental difference in the questions asked of those tools. With that in mind, I see no reason that a question should be off-topic simply because the method being used is code rather than an application’s GUI.

That isn’t to say that all code questions should be on-topic, only that the code in and of itself shouldn’t be reason for a question to be off-topic. As much as possible, the same reasoning in determining if a question is on- or off-topic should be applied regardless of the tools being used.

A few things to note…

  • A code question may very well be unclear or too broad, and should be closed as such.

  • If it is decided that implementation questions are off-topic then this would hold for code question too, but that should hold for all questions, regardless of whether it is a CSS question or a Photoshop question. The same applies for “tech-support” or any other close reason; all should apply regardless of the tools used.

  • If low quality code questions become a problem because of the code (i.e. the code itself is the problem, not a more fundamental reason such as being too broad), quality guidelines (e.g. requiring an MCVE) should be implemented that need to be followed for a question to be on-topic (much as we do for critique or font-id questions).

  • The fact that a question is on-topic on (or even better suited to) another Stack Exchange site should not be a reason for it to be explicitly off-topic here. It’s fine to direct someone elsewhere, but that shouldn’t exclude them from asking here.

How to determine if a code question is on-topic.

To be on topic, a question using code simply needs to either;

  1. Directly solve a visual design problem. That can be; “How do I draw an X sided polygon?” or “How do I increase line spacing?” or “Does this color convey X, Y or Z?” etc.

  2. Address an issue that a visual designer may reasonably face. This is a bit more fuzzy but akin to how, for example, questions about client management, workflow, automation etc. are all on-topic but not visual design problems. An example using code could be “How do I load a custom font in CSS?” or “How to semantically markup a CSS grid system?”.

With the aim of consistency, a rule of thumb for determining if a question is on-topic should simply be (similar to Wrzlprmft’s suggestion); If a sufficiently similar question using tools other than code would be on-topic then it is likely on-topic too.

The aim here is consistency. That is all.

Note, I am purposely considering this at a very fundamental level. Without establishing a fundamental reasoning for dealing with code questions, any distinction seems arbitrary.

I’m also mostly considering this with HTML & CSS in mind; if there was an influx of jQuery or more technical questions then maybe there would need to be further discussion on the matter, but that isn’t the case as of now.

  • 2
    I agree 100% with this as I've been advocating it for some time. I would also say that this should extend to all areas not only webdesign.
    – Ryan
    Sep 18, 2017 at 17:09

Furthering the mentality of my answer in one of the linked meta questions (I have a lot more experience with GD.SE than when I posted that answer), I would argue that all HTML or CSS questions dealing primarily with code implementation should be off topic. They are essentially tech support questions, of which we already have too many from design software. We should limit our scope to only questions regarding the theoretical-level graphic design nature of web questions.

Questions dealing with web-related code can already be asked and answered on other Stack sites like StackOverflow or others (depending on the exact question).

So more theory questions such as these should be kept:

And implementation questions like this should be closed:

I think that this is the only way to be consistent while still allowing the majority of web-related questions that have been asked here.

  • 2
    When does an html or css question not primarily deal with code implementation? No criticism, just curious. :)
    – Vincent
    Sep 11, 2017 at 9:05
  • 1
    To second @Vincent: Your criteria are too fuzzy for my taste. How can we see that a question “deals primarily with code implementation”? What exactly makes for a “graphic design nature”? Can you elaborate your criteria so that the community can apply them consistently?
    – Wrzlprmft Mod
    Sep 11, 2017 at 9:20
  • My graphic design problems frequently have to do with HTML and CSS. Without opening a discussion on the differences between art, design and engineering I think the nature of this question is about the scope of GDSE. Graphic design is becoming increasingly technical and code based and this SE has to has to address that. However the line needs to be drawn somewhere. When the question is purely code, or automating a function in a graphics program, it may belong in another section.
    – Webster
    Sep 12, 2017 at 0:12
  • 1
    @Vincent I've updated my answer Sep 12, 2017 at 1:36
  • 1
    This seems to fall in line with the Help Center's bullet point of on-topic questions: the look & feel aspect of web design. Further, the page explicitly lists web-site architecture and development under What not to ask.
    – TylerH
    Sep 13, 2017 at 14:30
  • 2
    Your answer is a critique of the technical off-topic close reason. As the current technical reason has 11 upvotes and no downvotes or criticism, I consider this answer erroneous because it contradicts what we just decided is our technical rational.
    – Ryan
    Sep 13, 2017 at 18:03
  • @Ryan Downvoting a discussion of a new policy suggestion simply because it isn't the old one seems like flawed logic to me :P I would think we should vote on answers here based on the answer itself, perhaps leading to changes in other aspects of GD's policies if need be once we figure out what we want to do here Sep 14, 2017 at 1:07
  • 2
    Hi Zach, I see the idea you're getting at, but I think it's very murky from your examples to see where the line is regarding what's on/off topic. There is an issue hinted at by your own answer in your fourth example: What is considered best practice by a web dev + what is rendered to a screen by a non-dev designer (haphazardly) may yield the same visual result; this begs the question as to how much detail should be given to answers where best web practice is a concern.
    – johnp
    Sep 14, 2017 at 2:27
  • @johnp Thanks for the reply. I'm not understanding exactly what you mean about it not primarily dealing with graphic design, but I realize this isn't the place to discuss it in detail. Maybe chat would be better for that? Sep 14, 2017 at 5:06
  • 3
    @ZachSaucier: because it isn't the old one – I think you are misunderstanding something here, because that’s not how I read Ryan’s comment at all. He was referring to your sentence They are essentially tech support questions, of which we already have too many from design software, which seems to ignore our brand-new change of policy on that matter.
    – Wrzlprmft Mod
    Sep 14, 2017 at 7:36
  • This particular new policy suggestion should be on the technical close discussion is what I'm saying. We shouldn't agree to leave tech questions if graphic designers is the best person to ask when they relate to topic A but then close then when they relate to topic B.
    – Ryan
    Sep 14, 2017 at 10:08
  • Ah, I understand now. Thanks! I still hold to my view in this answer though Sep 14, 2017 at 17:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .