“Select All” (of an element kind)

Sitely suggestion
1

A “Select All” command, (or a tool), which selects all of a specific kind of element exclusively. Example: This would be helpful to select all text on a page without selecting any other elements.

Why: Digital editing is of prime urgency. Planning of most websites occurs outside Sitely and a considerable possibility is that some authors may subsequently discover a love for Sitely after their sites were established uniquely, (and it is too late to adopt Sitely’s rules of planning, as indicated in another post here). Furthermore if a Sitely user inadvertently lost access to their Sitely files and needed to edit their page, this would block their access to their own styles, and they would be stuck importing this work as htmls).

Method: All text elements in a long sequence alternating with differing elements may need a change of styling, ubiquitously. This need might occur long after page creation. This need arrises with many individualized text blocks found in Sitely which take a long time to edit universally.

Also, aligning other specific elements vertically can be tedious on extra long pages, so select all buttons or all icons or all headers of particular kinds could be useful to edit vertical placement.

With my limited experience in Sitely, other categories of similar functionality are not found in Sitely.

This feature is found in some good 3d apps, and it overcomes densely populated obscuration of object kinds in crowded 3d space, and 3d objects would be somewhat equivalent to element types in Sitely, of which cannot be uniquely drag selected, (because all element kinds are included instead of one kind).

2

While the idea of a “Select All by Element Type” command sounds useful on the surface, in practice it would likely have limited usefulness for editing content in Sitely because of how HTML pages are structured.

In HTML, most elements - such as text blocks - are not a single unified object type across a page. Each text element is normally an independent element in the document structure (for example a <p>, <div>, <h1>, etc.). These elements may look similar because they share styling, but technically they are separate objects.

The important distinction is that shared appearance is normally controlled through styles, not through the elements themselves.

For example:

  • A number of text blocks might use the same style class
  • That style defines attributes such as font, size, colour, spacing, etc.
  • If you change the style definition, every element using that style updates automatically

So if the goal is to change typography or colour across many text blocks, this is already solved through editing the shared style, rather than selecting every text object individually.

Where things become problematic is with editing the text content itself. A command that selects every text element on a page would not really help here because each element contains different text. Editing them as a group would not make sense - changing the text in one would overwrite all the others.

In other words:

  • Styling changes → handled globally via styles
  • Content changes → must remain individual

Because of that separation, a “select all text elements” command wouldn’t provide much practical benefit for most editing workflows.

The situation is also a bit different from some 3D design applications. In those environments, selecting all objects of a type (lights, meshes, cameras, etc.) can be useful because those objects often share identical properties that are meant to be adjusted together. In HTML layout, however, elements tend to share styles, not content, which already provides the mechanism for global updates.

Regarding imported HTML where styles might not be accessible: even there, the underlying structure still consists of independent elements, so bulk editing of the text itself would still be problematic.

For layout alignment tasks (for example aligning icons or buttons vertically on very long pages), selection tools can certainly be helpful, but those workflows are usually handled through layout containers, grouping, or shared positioning rules, rather than selecting every instance of an element type across the entire page.

So while the idea is understandable, the way HTML structure and CSS styling work means that the functionality would probably be less useful in practice than it initially appears.

3

Well said for long time users and new beginners of Sitely specifically, (and indeed I still need to learn more pertaining details).

I too support priorities of developers, in case this unchangeable-ness with fonts was a big priority. I hope not to interfere, but in case developers are indifferent to after-thought-users, as with a font collection, and in long edited sets, then the suggestion may be harmless.

No doubt it would become natural to start every new site with a permanent style in that project if we knew the rule on day 1 of a project. If we hadn’t been preoccupied with decades of content.

I speak as a plea for another kind of user: One with decades of changeable style-conveniences, in my case with two previous website apps, decades of differing 2d + photo and publishing apps initially for paper print, (pre-www), and making just one website for voluminous content in the old Renaissance style of integral disciplines, and these involved plenty of intricate rules already.

Also I encounter other self-publishers on the www, looking for a tool like Sitely. Small enterprises with lots of earlier work to refurbish, or part time hobbyists also refurbishing pre-existing formats of some kind, and such people might miss that rule of unchangeable-ness in the beginner’s flurry of learning new apps. Then we are stuck 36 pages and still counting.

Or please enlighten me. Could we just make the required style setup in a new project and re-import our 36 Sitely-built html pages, back into Sitely’s new, properly setup project, and thereby obtain our wanted fonts exclusively without the ones that strayed into out first long project attempt?

1 Like
4

Yes, would love to see something like this! :slight_smile:

An optional "Style page’ where us more advance ones can introduce font style(s), colour, and global elements like buttons and patterns per project. :100:

1 Like