Re: View Source (was: SVG Feedback on HTML5 SVG Proposal)

On Mon, Mar 16, 2009 at 5:31 PM, Doug Schepers <schepers@w3.org> wrote:
> Hi, Raman-
>
> T.V Raman wrote (on 3/16/09 12:58 PM):
>>
>> And this is why in gneral, it would be a good idea for
>> show-source to perhaps show a cleaned-up serialization, rather
>> than the original tag-soup that was authored.
>
> I think everyone is on board with this idea, not just for SVG and MathML,
> but even for HTML... if someone out there has a good rationale against it,
> I'd be curious to know what that is.  Note that there are a couple of open
> questions:
>
> 1) Would the HTML (or other spec) *mandate* a "view source" mechanism? It
> could be on right-click, or as a menu option, or whatever; but as I
> understand it, the HTML spec steers well clear of any such normative
> behavior on UAs... I personally don't see why we couldn't make a conditional
> normative statement, such as, "For user agents which expose markup source
> code to users (such as a "View Source" menu option), the user agent must
> (should?) normalize the DOM serialization to present a valid and well-formed
> document."  It could go further and say, "For languages intended for use in
> XML parsers, such as MathML, SVG, or XHTML, the serialization must be valid
> for that language."  (Or something.)

In short, I don't think we should mandate this, nor do I think there
is a need to.

Proper development tools for the web is something that we're just
starting to figure out. I think that whatever behavior we'd mandate in
the spec would probably be obsoleted by better ideas a year from now.
In fact, we might even be mandating a worse UI since we're tying UI
designers hands. A point is case is the HTTP1.1 spec that demands that
users be informed about POST requests. This probably seemed like a
good idea at the time, but we now know that this has resulted in
redundant features in the spec (302 and 303 redirects being
essentially the same) and preventing developers from using features
properly because of bad UI experience (307 redirects pops up a ugly
dialog).

I also don't think there is need for any specific UI. Competition is
already starting to heat up in the development tools area as this is
an important area where browsers can compete. What keeps these tools
from having optimal UI is knowing what optimal UI and shortage of
resources. Neither of these issues will be helped by us mandating UI.

For example by demanding that a cleaned up source is displayed, some
UAs will probably choose to serialize the source such that it
guarantees that the page still works. That means that no whitespace
can be added for indentation, and no 'residual style nodes' can be
removed. So for example the cleaned up serialization of

<b><i><i><p>hello</b></i></i>

would be

<b><i><i></i></i></b><i><i></i></i><p><i><i><b>hello</b></i></i></p>

whereas a UI that allows the user to opt-in to to more aggressive
cleanup could serialize to

<p><i><b>hello</b></i></p>
or even
<p class="class1">hellp</p>
with a stylesheet.

What I *do* think we could do is to have an informal text that
suggests that implementations with view-source or other development
tools consider allowing a cleaned up DOM to be serialized.

/ Jonas

[1] http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%0A%3Cb%3E%3Ci%3E%3Ci%3E%3Cp%3Ehello%3C%2Fb%3E%3C%2Fi%3E%3C%2Fi%3E

Received on Wednesday, 18 March 2009 02:23:25 UTC