Re: [whatwg] scripts that remove focus from links during document navigation
On Wed, 20 Sep 2006, Hallvord R M Steen wrote: Opera has a serious usability problem for keyboard- and device-users when pages do the following: a href= onfocus=this.blur() This coding is very common because IE adds a small outline border to focused links. Authors who do not like this will blur links when they are activated to avoid this cosmetic issue. (Mea culpa: I've done exactly this myself in sites I coded as a newbie, for that very reason.) In Opera, when keyboard navigation hits this link, focus is removed. Thus the link can not be activated from the keyboard and navigation may have to start from the top of the document again. We need some prose in a spec that allows a user agent to ignore blur() for accessibility reasons. Done in HTML5, which seems to be the only spec that actually defines blur() in any sort of useful detail now. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Is EBCDIC support needed for not breaking the Web?
The HTML5 draft says that authors should not use EBCDIC-based encodings. This is more lax than saying that authors must not use and user agents must not support CESU-8, UTF-7, BOCU-1 and SCSU. In general, now that UTF-8 exists and is ubiquitously supported, proliferation of encodings is costly and doesn't expand that the expressiveness of HTML which is parsed into a Unicode DOM anyway. Moreover, encodings that are not ASCII supersets are potential security risks since the string script may be represented by different bytes than in ASCII leading to potential privilege escalation if a server-side gatekeeper and a user agent give different meanings to the bytes. For these reasons, if EBCDIC-based encodings don't need to be supported in order to Support Existing Content, it would be beneficial never to add support for them and, thus, ban them like CESU-8, UTF-7, BOCU-1 and SCSU. I asked Hixie for examples of sites or browsers that require/support EBCDIC-based encodings. He had none. I examined the encoding menus of Firefox 3b5, Safari 3.1 and Opera 9.5 beta (on Leopard) and IE8 beta 1 (on English XP SP3). None of them expose EBCDIC-based encodings in the UI. (All the IBM encodings Firefox exposes turn out to be ASCII-based.) This makes me wonder: Do the top browsers support any EBCDIC-based encodings but just without exposing them in the UI? If not, can there be any notable EBCDIC-based Web content? I'm suspecting that EBCDIC isn't actually a Web-relevant. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Is EBCDIC support needed for not breaking the Web?
* Henri Sivonen wrote: This makes me wonder: Do the top browsers support any EBCDIC-based encodings but just without exposing them in the UI? If not, can there be any notable EBCDIC-based Web content? Internet Explorer should support any character encoding Windows supports (see the advanced tab in `control International`), which includes many EBCDIC encodings. See eg. http://www.websitedev.de/temp/ebcdic-cp-us.txt for an example. It seems to me [EMAIL PROTECTED] would have been a better place to ask your questions than the mailing lists you picked. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Is EBCDIC support needed for not breaking the Web?
On Jun 1, 2008, at 17:25, Bjoern Hoehrmann wrote: * Henri Sivonen wrote: This makes me wonder: Do the top browsers support any EBCDIC-based encodings but just without exposing them in the UI? If not, can there be any notable EBCDIC-based Web content? Internet Explorer should support any character encoding Windows supports (see the advanced tab in `control International`), which includes many EBCDIC encodings. See eg. http://www.websitedev.de/temp/ebcdic-cp-us.txt for an example. Thanks. Philip Taylor made a test case: http://philip.html5.org/demos/charset/ebcdic/charsets.html It shows that browsers that use general-purpose decoder libraries (IE and Safari) support some EBCDIC flavors but browsers that roll their own decoders (Firefox and Opera) don't. Firefox and Opera being able get away with not supporting EBCDIC flavors suggests that EBCDIC-based encodings cannot be particularly Web-relevant. Even if saying that browsers MUST NOT support them might end up being a dead letter, it seems that it would be feasible to say that browsers SHOULD NOT support them or at least MUST NOT let a heuristic detector guess EBCDIC (for security reasons). (Also, I think I'm going to remove EBCDIC support from Validator.nu.) It seems to me [EMAIL PROTECTED] would have been a better place to ask your questions than the mailing lists you picked. So many lists. :-( CCed that one, too, just in case. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Is EBCDIC support needed for not breaking the Web?
[just to whatwg] 2008/6/1 Henri Sivonen [EMAIL PROTECTED]: Philip Taylor made a test case: http://philip.html5.org/demos/charset/ebcdic/charsets.html It shows that browsers that use general-purpose decoder libraries (IE and Safari) support some EBCDIC flavors but browsers that roll their own decoders (Firefox and Opera) don't. I just loaded that test page in Firefox 3 on Linux (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008052604 Minefield/3.0pre) and the accented characters appear to work in the EBCDIC encodings ... - d.
Re: [whatwg] Proposal for a link attribute to replace a href
-Original Message- From: Anne van Kesteren [EMAIL PROTECTED] Sent: May 31, 2008 5:02 AM To: Ernest Cline [EMAIL PROTECTED], WhatWG [EMAIL PROTECTED] Subject: Re: [whatwg] Proposal for a link attribute to replace a href On Sat, 31 May 2008 04:20:10 +0200, Ernest Cline [EMAIL PROTECTED] wrote: What about adding a third non-metadata hyperlink element, say anchor, which would be a flow content element with flow content allowed in it? This would seem to cover the use cases presented, while preserving a as being phrasing content only. The only issue I see if this were added, is whether it would be better to have the ismap attribute of img only work with a or to have it work with the new element as well. The a element can already do this and it would be backwards compatible. Backwards compatible with some user agents but not with the specs. The following fragment has never been valid according to the specs in any of HTML 1.0, 2.0, 3.2, or 4, or the current draft of HTML 5, despite a, h3, and p appearing in all of them. a href=foo.html h3Heading/h3 pText/p /a The specs have always called for a to only have inline content save that for some reason, HTML 2.0 did allow h1 to h6 inside a though that was not recommended, and that was reverted back to inline only in 3.2. While changing the specs to match user agent behavior is a possibility, it is not one that should be taken lightly. (Nor should adding a new flow content hyperlink element, be taken lightly either.)
