W3C home > Mailing lists > Public > public-html@w3.org > April 2007

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

From: David Hyatt <hyatt@apple.com>
Date: Mon, 16 Apr 2007 16:53:35 -0700
Message-Id: <0D760F7E-2B9C-4C96-974F-03AB57292117@apple.com>
Cc: murray@muzmo.com, mjs@apple.com, public-html@w3.org
To: "T.V Raman" <raman@google.com>

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
>
Received on Monday, 16 April 2007 23:53:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:42 UTC