[Webkit-unassigned] [Bug 36481] Web Inspector: Edit Tag Names

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=36481





--- Comment #5 from Joseph Pecoraro <joepeck at webkit.org>  2010-03-23 23:12:43 PST ---
Thanks for the comments. I'll further then discussion.

> - Given a node with N children, Add Child only solves 1/N part of the problem.
> I.e. Besides "Add Child" we need "Insert Above" and "Insert Below".

> Or have 2 other menu items, Add Previous Sibling and Add Next Sibling and you
> are done. Add Child would be there too.

I think Drag & Drop reordering would handle this nicely. I did originally plan
on having "Add Next Sibling" but I didn't get it in before midnight so I
stopped with this patch =).

> - I did not track it in the code, but according to the video, adding text nodes
> capability is missing

You're correct. Great point! Anything left? Processing Instructions / Comments
would be over overkill.

> - Taking #2 to the greater level, I think Add / Insert Child should be
> implemented as Edit as HTML. I.e. accept free flow text as an input. That way
> user would be able to paste portions of HTML as a source for new nodes. I know
> we lose nice structuring of added nodes, but we gain huge flexibility in
> return.

> I like Edit Tag! I think it is easier than Edit HTML. I would like to see the
> close tag update as you type the new tag name. It was weird to me to see it
> stay as the old tag until commit, espicually in a structured edit mode (not
> free form),
> 
> I think I might agree with Pavel that adding a new element should just just be
> free-form and not structured. But I'm on the fence. I usually prefer the
> structured mode…

I am a big fan of the structured mode. Mostly because it typically handles
errors more gracefully. At the very least, if I want to create an element right
now the first thing that comes to mind is _not_ "Edit HTML". Instead I'd rather
$0.appendChild(document.createElement(...).


It sounds like I should add the following context menu items. Any way to limit
this without something too clever? With Drag and Drop we could just have "Add
Sibling" and have the user drag it after making it.

  - Edit Tag
  - Add Child Element
  - Add Child Text Node
  - Add Previous Sibling
  - Add Next Sibling





> > +using namespace HTMLNames;
> > +
> 
> I think our relationship with HTMLNames is not strong enough to start using
> using.

Point taken. Is there a convention here?


> > +        frontend->didRemoveNode(callId, -1);
> 
> Bug. -> didAddChild ?

Good catch.


> > +        newElem->copyNonAttributeProperties(oldElem);
> 
> Does this take care of JS properties on wrappers?

I actually don't even know what it does. Shame on me. 

What do you mean by property wrappers? Just generic properties added to the
node via JS? Can anyone think of things I should copy other than Attributes and
Children?


> > +    if (code) {
> > +        frontend->didChangeTagName(callId, -3);
> 
> Do you handle these error codes? If not, why differentiating?

This was actually debugging code for me, to know when it error'd out. I can
change them all to -1.

> > +            // Short delay for the UI to catch up
> > +            setTimeout(function() {
> 
> Oh no.
> 
> I'll review front-end code in greater detail later.

Again, I wanted to get some discussion out the door (which it looks like I
did). I have to investigate a number of UI issues with this patch. You can hold
off a detailed look, I may ask you some questions on IRC the next time I look
at this.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.