Re: validator results page - don't break web with fancy features - show information with more clicks

Olivier,

olivier Thereaux wrote:
...
 > Thank you for this thoughtful and detailed message.

You're welcome.

 > On Mar 9, 2007, at 04:58 , Daniel Barclay wrote:
...
> 
>> However, I do notice two problems:
>>
>> 1.  Something in the page structure prevents the browser from wrapping
>>     the wrappable text (the error message text, e.g., "You have used
>>     the attribute named above...") to fit the browser window.  The
>>     page requires the user to scroll horizontally more that the user
>>     should have to do so.
> 
> 
> This is because of a very long line without any space in the source 
> display, making the viewport extremely wide.

No.  That is not the (complete) reason.  I think you misunderstand the
issue and/or what's going on with the formatting (or which part I was
trying to address).


The problem is not that a very long line is making the overall web
page very wide.  That part is normal behavior.

(The reason it's not the problem is that making the overall web page
very wide does _not_ (by itself) cause wrappable text to be wrapped at
the width of the page or the long line that makes the text wide.
Without some other problem, the wrappable text can still wrap at the
browser window width.)

For example, for a page like this:

     ...
     <body>
       <pre>a very long line .............................. </pre>
       <p>
         Regular text. Regular text.
         Regular text. Regular text.
         Regular text. Regular text.
         Regular text. Regular text.
       <p>
      </body>
      ...

the parapraph (P) text will wrap to fit the browser window even if
the preformatted line doesn't fit in the browser window and makes
the page wider than the browser window.

Note the important point:  The user will not have to scroll
horizonally to read the regular text (the paragraph text).

(Yes, of course, the user will have to scroll horizontally to see
the preformatted text.  That's reasonable.)


The problem I was referring to is that something in the structure
of that results page ties (links) the width of the wrappable text to
the wide of the long lines.

For example, this structure will cause that problem>

     ...
     <body>
       <table>
         <tr>
           <td>
             <pre>a very long line ......................... </pre>
             <p>
               Regular text. Regular text.
               Regular text. Regular text.
               Regular text. Regular text.
               Regular text. Regular text.
             <p>
             <p> ... more ... </p>
           </td>
         <tr>
       </table>
      </body>
      ...

(Structures other than actual HTML table elements can cause the same
problem.)

With that structure, the preformatted line determines the minimum
width of the table column.  Then the table column's width is used for
each cell in the column.  Finally, the cell's width is used to wrap
each paragraph's text.

The result is that the wrappable text is wrapped at the width of the
preformatted line, instead of being wrapped at the browser window
width.  If the preformatted line comes out wider than the browser
window width, then even the wrappable text is wrapped at a width
that is wider than the browser window width.

Again, note the important point:  The user has to scroll horizontally
to read _any_ part of the text (not just the preformatted text, for
which having to scroll horizontally is reasonable).

In particular, note that the user has to scroll horizontally to read
_each_ line of wrappable text, and, even worse, the user has to scroll
_twice_ for each line:  first to the right to read the end of a line,
and then back to the left to read the beginning of the next line.


Now compare the two cases.  The first case shows that it is possible
for a page to contain wide, non-wrappable content that does not force
the user to scroll horizontally to read the wrappable content.  The
second case clearly forces the user to scroll horizontally even when
the user shouldn't have to.

(Be sure to imagine the case with several "windowfuls" of regular
text, then one long, preformatted line, and then several more
windowfuls of text.  In particular, one would not want one long,
preformatted line in the middle of a web page to force all wrappable
text to wrap to a width that might be wider than the browser window
and thereby the user to scroll horizontally twice to read each
line.)


On the HTML validator results page, the particular problem seems
to be that wrappable error message text is enclosed in the same box
as the preformatted snippet of source code near the error location.

Presumably, that was done to get the light gray lines around and
between the error reports.

The page designer should (try to) find a way of generating the
intended visual design without tying the wrappable error message
text to the preformatted code-snippet text.




...
>> 2.  The Cleaned-Up Source section has a serious usability problem
>>     because it tries to do scrolling internally:
> 
> That is not a bug, it's a feature. Unlike the source display above, the 
> tidied source is there to be copy-pasted, not looked at extensively. 
> This is why it is put in a pre, with scrolling overflow, to avoid making 
> the global window too large (something you agree is a usability problem, 
> see your comment above).

Actually, I don't agree that that is the problem.  (Again, I think
you misunderstood which part of the behavior I was addressing.
Hopefully my explanation above has clarified that.)

The problem is not making the overall page too wide.  The problem is
tying the width of wrappable text to the overall page width (or to
anything that might be wider than the browser window width).


If adding scrolling overflow to the PRE element for that source
really did affect the width of any other part of the web page,
something else is wrong with the structure of the web page (e.g.,
the width of the wrappable error message text is tied to the width
of the PRE element in a way that it should not be tied).

No, the page does not seem to have that structural problem.  The
Source Code section can be very wide, and even though it makes the
overall page very wide, it does _not_ force the error-message text
to be any wider.  Therefore, the error-message text is not tied
to the width of the Source Code section.  Then, given that the
cleaned-up source section is on the other side of the Source Code
section from the error message section (that is, the Source Code
section is between the error-message section and the cleaned-up
source section), it doesn't seem that the cleaned-up source section
needs the auto scrolling.

So, given that the cleaned-up source section does not seem to need
auto-scrolling, and given the bad problem with auto-scrolling I
pointed out before, it certainly seems that the cleaned-up source
section should not have auto-scrolling.


(You say that section's auto-scrolling is a feature (as opposed to
a bug).  However, it doesn't seem to accomplish what I think you
implied it accomplishes (avoiding making other text on the page wider
than it should be).  Therefore, since it doesn't accomplish that, is
it really a feature?  Or is it a feature that accomplishes something
else?)


Thanks.

Daniel

Received on Friday, 9 March 2007 17:11:26 UTC