An alternative:

* Call this community html.ta ('HTML and CSS'), and include closely related areas like SVG, LESS, but not Javascript
* Have javascript.ta covering jQuery (but not npm or node.js specific questions)
* cross-feed html.ta and javascript by default
* php.ta as a standalone community
* webserver.ta covering Apache, Node, etc (Node developers can manually cross-feed from javascript.ta and vice versa, PHP devs from php.ta etc)

There are two main types of questions I would like to be able to ask here:

1. I am building something on the web; how do I do X?
2. I am a consumer of a web site and need to be able to adjust my experience; how do I do this userscript/CSS override/browser extension to solve my problem?

I see these as related even though they're from different "sides"; if, for example, someone in #1 did accessibility differently then the question in #2 might not arise, but we live in an imperfect and ever-changing world.

#2 runs the risk of veering into general browser questions (how do I do such-and-such in Opera?), so we should decide early on if we're ok with general browser questions.  The site is currently called "Web", not "Web Development", so I think there's justification for some amount of "consumer" content, but I don't know how much is fine and how much is too much.

Whatever other nuances of scope we decide on, I think we should make a strong distinction between server-side and client-side, and keep everything server-side off topic here.

So PHP, ASP, apache, nginx etc should be out of scope. We probably need a *webserver*.*ta* for those.

What does Web.TA think about supporting particular "platforms". SO has a fairly full set of `wordpress-*` tags, for example, also `expressionengine`, `drupal`, etc. etc.

The case may be fairly clear for such systems, and insofar as they involve HTML, CSS, and JavaScript, all good. Does this extend to PHP, Ruby, Angular... (and React is javascript, after all) based frameworks/portals/cms/etc?

One potentially grey area would be requests for **recommendations**, typically for software, but they could also be for web technologies to meet a particular use-case. (In the SE network, SoftwareRecs allows for e.g. `[cms]` requests for particular scenarios.)

Such questions frequently shade off toward "opinion based", unless the question is framed with particular care.

I think my personal preference at *this* moment would be to regard sharply-written requests for recommendations as **on-topic**. Almost inevitably, especially as the community grows, such questions will appear, and they can be valuable. Vague or blatantly opinion-based questions could be edited into shape, or refined *via* the integrated chat system, or consigned to oblivion if beyond retrieval.

*P.s. I assume we want to populate this Q&A with a variety of responses, some of which will be (even intentionally) "bad" in order to describe boundaries (inclusion and exclusion) effectively.*