Feature request: source loupe to edit HTML code

Welcome! Forums TypeMetal Support Feature request: source loupe to edit HTML code

This topic contains 9 replies, has 2 voices, and was last updated by  Troy Stephens 3 years, 7 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)

  • Author


  • #299

    Jean-Philippe Humbert

    Hi Troy,

    I’d like to use the source loupe as a mini HTML editor.
    – Turn Source Loupe on
    – Select the part of the page that I want to change
    – Clicking on this part
    – Now I should be able to directly edit HTML code in the source loupe
    – Turning the source loupe off or scrolling thru the html page should refresh it.



    Troy Stephens


    Hi Jp,

    It’s not out of the question, but the Source Loupe was designed primarily to be transient UI that you don’t need to use very much. Its main purpose is to earn confidence in the HTML that TypeMetal produces, and secondarily to provide another way to inspect HTML that’s been opened or pasted/dropped from other sources.

    I wonder if your question is indicative of some kind(s) of editing operations you want to do that aren’t easily or efficiently performed (or obvious how to perform?) using TypeMetal’s existing WYSIWYG editing UI?

    What I’d really love to do is identify such cases and figure out how the desired editing goals can be facilitated within the main, visual editing UI. Making the user drop to source code editing for certain operations (except maybe for editing generalized snippets :-) feels sort of like a design failure.



    Jean-Philippe Humbert

    Well one example:

    I inspect my code with the source loupe and see that some attributes, which are not visible, need to be corrected. How can I edit them?

    something like <div class=”NOT CORRECT”></div>

    I see how to edit but not how to edit <div>


    Troy Stephens


    There are many ways to get hold of an element and open the attribute editor for it. Let me know if there’s a way I could present this functionality that would have made it easier to discover.

    One way is to put the insertion point or selection somewhere inside the <div>. Type Cmd+Opt+G to grow the selection repeatedly until the <div> is selected. (It will be highlighted in the path bar.) Then type Cmd+L to show the attribute editor.

    You can also right-click the <div> in the path bar, and choose “Edit Attributes of <div>”. (Note that there are many other useful capabilities in the same path-segment context menu too.)

    Or, in Block Mode, you can click the handle at the right edge of the <div> to select the <div>. Then Cmd+L to get the attribute editor.

    Once you have the attribute editor open, note that there are many ways to get to the “class” attribute to edit it. You can type “c” in the search field, then [space] or [return] to complete it and jump to the “class” attribute’s value field. Or you can down arrow to it if you prefer. And if you want to remove the “class” attribute instead of changing its value, you can just type Cmd+[delete] while the insertion point is in the “class” value field.

    Here’s a fairly complete list of keyboard shortcuts, by the way.

    Hope this helps!

    • This reply was modified 7 years, 9 months ago by  Troy Stephens. Reason: added a link


    Jean-Philippe Humbert

    Well I tried to do it your way but it is not practicable for me:
    – With Cmd+Opt+G I can select “some” div but I don’t know if it is the right one, because I can’t see all attributes. I need for each div to open the attribute editor. It’s to slow and to complicated.
    – The same happens with block-node …

    I still prefer using BBedit / Sublime Text for this


    Jean-Philippe Humbert

    A practicable solution for me could be:
    – Within the source loupe I select the element I want to correct
    – I open the element attribute and correct it => It works

    – Selecting the right element (div in my example) is not always easy: Could you implement two shortcuts to select the previous/next element?

    – I can select approximatively the element where a problem happens and I want to be able to jump to the previous/next element until I find the right location …

    It’s maybe still “texteditor” orientated but I think it could help.


    Troy Stephens


    Ah, I understand!

    I’ve been thinking about adding keyboard shortcuts for easily navigating to the next/previous node or element, and about having those shortcuts (as well as Cmd+Opt+G) work when the attribute editor is open — so one could hop the attribute editor from one element to the next, previous, or containing element, without having to close and reopen it. (Drilling down into the DOM tree could be useful too, though there’s ambiguity about which child node/element to hop to when an element has several children. Maybe first, or middle, or last, would be a reasonable choice. I could also remember and try to return to where the user had started from in a series of such navigation steps, when ambiguity arose when drilling down.)

    Sounds like the other part of the problem is that there isn’t a way to see attributes other than “class” and “id” (whose values show up in the path bar), except by looking in the Source Loupe or opening the attribute editor to peek. I will give some further thought to ways to make those attribute visible and more readily accessible (perhaps a tooltip on mouse-over, or display of additional attributes in the path bar?). I have also planned to add an enhanced Find feature, that will enable one to search for elements (by tag and/or attributes) in addition to searching for just document text, and a facility for browsing and navigating to “id” and “a name=” anchors in particular.

    Do the things I’m proposing sound like they would solve the problem for you?


    Jean-Philippe Humbert

    Yes that’s what I need.
    For the attributes I don’ t think that you can have enough place in the pathbar. Maybe an optional “Info window”?


    Troy Stephens


    Yes, I was thinking the same — it could be too much to put into the path bar segments. But maybe a good compromise would be to show at least one such attribute, and an indication (ellipsis?) that the element has more that are not shown. Mousing over the path bar segment could show all of the element’s attributes, in a tooltip perhaps.

    An “Info” window would be another possibility. If possible and within reason, I’d like to try to fit such functionality in the document window itself. But there are times when a floating inspector window can be useful or appropriate.

    Thanks for the very helpful feedback and suggestions! I’ll work on this!


    Troy Stephens


    In the just-released TypeMetal 1.2, you can now double-click an element’s start or end tag in the embeddable Source Loupe to open the Attribute Editor for that element. If you double-click a particular attribute’s name or value, TypeMetal will even open the Attribute Editor with that attribute’s value already focused for editing.

    I hope this helps make what you want to do much easier! Please let me know how I can further improve the experience for you!


Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.