W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2001

Re: Minimal Browser Capabilities

From: Vadim Plessky <lucy-ples@mtu-net.ru>
Date: Wed, 26 Dec 2001 14:06:33 +0000
Message-Id: <200112261106.fBQB6kH18509@post.cnt.ru>
To: Charles McCathieNevile <charles@w3.org>
Cc: <w3c-wai-ig@w3.org>
On Tuesday 25 December 2001 13:00, Charles McCathieNevile wrote:
|   Folks, please note that this is an open issue in the WCAG group - it is
| in the iossues document as issue 77 but has no anchor to point to - search
| http://www.w3.org/WAI/GL/wcag20-issues for "77. Documenting assumptions" or
| go backwards from http://www.w3.org/WAI/GL/wcag20-issues.html#2 - so it
| would be helpful for people who are going to follow this here to send their
| final conclusions to the WCAG grup as input on that issue.

As a first try, I think Minimal Browser Capabilities should be:
* XHTML basic (or XHTML 1.1, dependind on platfrom or on developer's opinion 
what version of XHTML is more simple to be implemented)
* CSS modules: Selectors, Visual Box Layout
(so that you can use #aa, .bb definitions for 'id' and 'class', plus apply 
them on DIV or SPAN in XHTML or define {display: block}, {display: inline} 
for XML elements
You can also add Background and Colors modules to the list, but they are easy 
to understand for traditional web-developers.
NOTE: I think Fonts module should be really optional, due to its bloatness.

* ECMAscript (JavaScript), I believe, is really *optional*
It should be requirement for *minimal* browser capabilities.
Besides, it can be that other languages (Python, for example) will be betetr 
suited for web-pages & scripting, so putting JS as requirement is not very 
* SVG , I think, is too fat to be included. May be, SVG Core? 

So, I think XHTML basic + CSS (without Tables, Positioning modules) is a way 
to go, and should be considered as a minimum requirement.
Under CSS, I was referencing to CSS3 modules, but of course many of them 
should be re-worked before becoming Recommendation.

As about Lynx - it seems that 
a) XHTML support should be added to it, if it's not done already
b) CSS Box Model can be emulated even on text screen.
You can suggest , say, virtual screen size of 800x600 (80x30 text) and use it 
for layouting, and make *rounding* to nearest *full* character.
Most likely, you will be able to get even CSS borders - if border is 
thick enough, of course. 

The best solution, of course, would be to have *rendering engine* separated 
from *User Interface*.
Than you can use same engine with Text Layout (terminal, DOS, your 
refrigirator on kitchen, whatever), Framebuffer (like QT/Embedded, SVGAlib or 
GTKembed) and normal 2D accelerated screen (XFree86, MacOS, Windows)
So far, none of browser vendors achieved this.
Opera, most likely, is the closest to this, but it seems they do not plan to 
make text-only browser.
I guess Opera in Sharp Zaurus PDA will operate over Qt/Embedded, so they have 
Framebuffer solution (also used in Opera for QNX), plus Windows, Mac and 
Linux ports. Now we should just ask Opera to add text-only browser :-)

|   cheers
|   Charles McCN
|   On Mon, 24 Dec 2001, Kynn Bartlett wrote:
|     At 8:49 PM -0500 12/24/01, Access Systems wrote:
|     >On Tue, 25 Dec 2001, Vadim Plessky wrote:
|     >  > Of course, you need to have JavaScript enabled to get this code
|     >  > working :-) // but you can't do any on-page browser detection
|     >  > without
|     >
|     >JavaScript, anyway.
|     >But Javascript is not normally on in Lynx.  (in fact I don't know how
|     > to enable it in Lynx or if it is even possible)
|     Lynx doesn't do JavaScript.  This should be considered a serious
| shortcoming in Lynx, but instead it seems to be viewed as a virtue.  I'd
| really like to see text browser that did JavaScript and CSS.
|     Anyway, the answer there would be a <noscript> fallback intended for
|     browsers which don't do JavaScript or which don't have JavaScript
|     enabled.
|     >I say it again, there should be no assumption what so ever that there
|     > is any user side support for anything.
|     Surely you don't mean "for _anything_".  Do you assume client-side
|     support for HTML 2.0?  What about HTML 3.2?  What about HTML 4.01
|     Transitional?  What about HTML 4.01 Strict?  What about CSS level
|     1?  What about CSS level 2?  What about ECMAScript?  What about
|     DOM?
|     See, we need to assume some level of basic support.  Okay, so some
|     browsers won't measure up to it -- but some browsers (such as Lynx)
|     have not been reprogrammed in 5 years.  More recent browsers do
|     indeed have some degree of all of the above, so the answer simply
|     is to ask what is the reasonable level of support to expect, and
|     is it fair game to expect someone to be using a reasonable browser
|     when accessing your site?
|     --Kynn


Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
KDE mini-Themes
Received on Wednesday, 26 December 2001 06:07:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:08:43 UTC