View Source question

[Eben Eliason]

On Mon, May 19, 2008 at 3:01 PM, Morgan Collett
<morgan.collett at gmail.com> wrote:
> On Mon, May 19, 2008 at 8:47 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
>> I believe the only two reasons that view source isn't yet what we all
>> hope it to be is a) because, when we got down to it, it became a
>> little difficult to specify exactly what that hope is, and b) because
>> there are so many other items on the plates of developers that the
>> last thing worth dedicating time to then was an unsatisfactorily
>> specified new feature.
>>
>> I don't think anyone disagrees with the desire to "pull back the
>> covers" though, and I also think that doing so can certainly have some
>> practical applications.  As Walter mentioned, in Browse their may be
>> options for viewing the HTML source, the CSS and JS is applicable, and
>> ultimately the bundle code of the activity.  This latter piece can be
>> made standard, and simply hasn't been yet because the means of
>> accomplishing this is the Develop activity, which is still in
>> development and testing.
>>
>> To throw my thoughts on the table, I'd vote for the view source key to
>> reveal a modal alert which contains the various options for "what to
>> dig into" in some form, one of which would always be the bundle
>> itself.  Through some API the activity could indicate what it can
>> offer, and perhaps also indicate whether or not it intends to handle
>> the request itself (that is, the Browse activity may wish to reveal
>> the HTML source itself).  This all clearly needs some more thought,
>> though.  Do others have refinements to the notion of this dialog,
>> regarding how an activity can offer up some goodies for peeking at
>> and/or how we can handle revealing those goodies through itself or
>> other activities? At least this approach will give a consistent
>> jumping off (or in, so to speak) point for the view source key,
>> regardless of what other interfaces or activities are then revealed
>> once an option is selected, and it provides a default behavior which
>> will work for every activity without explicit activity participation.
>
> I think one of the difficulties is maintaining some sort of context
> for progressive View Source operations. For example, View Source on a
> web page shows the page source in Write. View Source again should
> ideally dive into the Browse source, not the Write source...

Well, the model I'm proposing has pros and cons, but I think a pro is
that it does "handle" the circumstance you mention.  From within
browse, the view source dialog might offer "HTML", "CSS", "JS", and
"BUNDLE".  Clicking any of the first three could open them up in
Write, or in Browse itself if it wants to build support for it.
Clicking on the last would, for instance, open a Develop project. (To
be clear, I envision providing options for any supporting activities
for each available option....we shouldn't lock kids into using those
we choose up front, like Write and Develop).  This in any case, the
new context is still "just some activity", be it Browse, Write,
Develop, or something else.  Hitting view source again would
appropriately reveal the options which always appear for that
activity.

This gives up the arguably powerful onion-skin model for a simple and
consistent one whose behavior can be more clearly defined, and which
takes advantage of all the other (and future) activities on the system
which are capable of revealing various types of sources.  This is a
tradeoff I'm willing to make; others may feel differently.

- Eben