- From: David Hyatt <hyatt@apple.com>
- Date: Mon, 16 Apr 2007 16:53:35 -0700
- To: "T.V Raman" <raman@google.com>
- Cc: murray@muzmo.com, mjs@apple.com, public-html@w3.org
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