Re: Non-goal for HTML: Picture-perfect rendering

My personal preference would be to see this kind of styling
perfection achieved via CSS -- and for CSS to be
extended/augmented where it doesn't do the job.
I agree with you that CSS doesn't do everything today -- but then
it hasn't always done everything that it does today e.g. CSS
Selectors coming to gain most of the functionality that one
expected from XPath.
So I am bemused by the fact that CSS whose primary role in life
was styling HTML, would punt on things and let HTML specify
default rendering.

I do believe  that there is value in the HTML spec specifying
"visual user agents  shuold behave as if CSS xxx were in effect"
 in the absence of an accompanying stylesheet in terms of
 specifying default rendering. 

But trying to turn HTML into a pixel perfect layout language
will effectively turn it into a final form layout language a la
postscript -- that was never supposed to be its strength, and nor
should it be made so now.

David Hyatt writes:
 > I see your point.
 > 
 > Ignoring <canvas> for a moment, I do think there is a need for many  
 > elements to specify a more precise visual rendering.  Whether this  
 > rendering is normative or not can be debated, but when talking about  
 > desktop browsers at least, there is a very real need for browsers to  
 > try to agree on how such elements render.  Many purely visual  
 > interoperability problems have occurred on the Web between browsers  
 > because of HTML's deliberate imprecision regarding how these elements  
 > should render.
 > 
 > Forms are a great example of this... the rendering of form elements  
 > doesn't have to be identical across browsers to the pixel obviously,  
 > but browsers do at least need to agree typically on what the type of  
 > widget should be used for a specific value of <input>'s type  
 > attribute.  Fieldsets and legends are another example, where, for  
 > compatibility, a lot of the rules for how these elements visually  
 > position and render need to match.
 > 
 > Maybe it is not the domain of HTML to specify the rules (guidelines?)  
 > for such elements, but in cases where the rules are not expressible  
 > using current CSS constructs (which is the case with fieldsets and  
 > legends), whose job is it?
 > 
 > As I've said in a previous thread, <canvas> is a dynamic <img>, so I  
 > don't see any reason to object to the element purely on the grounds  
 > that it primarily defines a visual object.  Objecting to the  
 > inclusion of the graphics context API itself I can understand, since  
 > HTML doesn't specify how GIFs or PNGS should render, so why should it  
 > specify how a <canvas> renders?
 > 
 > However I also don't see the harm in inclusion of the graphics  
 > context API in the same specification mainly because of the time/ 
 > effort that would be involved standardizing it somewhere else (and  
 > those responsible for the three implementations of canvas that exist  
 > already are actively participating in this group).
 > 
 > dave
 > (hyatt@apple.com)
 > 
 > On Apr 16, 2007, at 4:17 PM, T.V Raman wrote:
 > 
 > > My message "if we're talking about pixel-perfect rendering, it's
 > > time to push the Reset button ..."
 > > applied to HTML the markup langugae fo rthe Web that was supposed
 > > to allow one to write Web pages without worrying about which
 > > vendor's browser or which kind of display the end-user was
 > > looking at the page on ... ---
 > >
 > > David Hyatt writes:
 > >>
 > >> <canvas> supports fallback for accessibility.
 > >>
 > >> dave
 > >>
 > >> On Apr 16, 2007, at 2:03 PM, Murray Maloney wrote:
 > >>
 > >>>
 > >>> At 11:07 AM 4/16/2007 -0700, Maciej Stachowiak wrote:
 > >>>
 > >>>
 > >>>> On Apr 16, 2007, at 10:39 AM, Murray Maloney wrote:
 > >>>>
 > >>>>>
 > >>>>> I couldn't agree more with T.V. Raman on this matter.
 > >>>>> I suggest that we promote this statement to the status
 > >>>>> of Design Principle.
 > >>>>
 > >>>> I disagree. Consistent rendering, to some extent and at least for
 > >>>> some media, is required for interoperability. Your proposed  
 > >>>> principle
 > >>>> would be in direct conflict with our interoperability goals.
 > >>>
 > >>> So you say. TV Raman and I disagree. Convince us.
 > >>> While you are at it, please explain how you propose to
 > >>> accomplish "Picture-perfect rendering" in braille and speech.
 > >>>
 > >>> Regards,
 > >>>
 > >>> Murray
 > >>>
 > >>>
 > >>
 > >
 > > -- 
 > > Best Regards,
 > > --raman
 > >
 > > Title:  Research Scientist
 > > Email:  raman@google.com
 > > WWW:    http://emacspeak.sf.net/raman/
 > > Google: tv+raman
 > > GTalk:  raman@google.com, tv.raman.tv@gmail.com
 > > PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
 > >

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman 
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Tuesday, 17 April 2007 00:04:37 UTC