Re: [whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?]
timeless ha scritto: i don't really want to spend a lot of time with this, but any feature authors are provided will be abused. among my list of things which i wish were never let out of pandora's box are defining accesskeys (instead of commands) in html, and another which i'd hope dies on the vine is aural css. sure it is theoretically nice to let someone encode audio. however on average it's going to be used more often by advertisers than actual content developers. Of course, advertisers could avail of aural CSS, but they can right now embed a voice registration into a flash ad, targeting a wider audience... the amount of effort required to invest in a feature which is generally not useful far exceeds any value offered to the user by the agent. in the case of accesskeys, a much more useful research area is to developer a browser global way of accessing content which works well for the device/useragent/user. enabling each site to design its own poor access keys is much less useful than letting browsers be configured by their users or share keybindings from one browser to another for a given site. Accesskeys are an attempt to reproduce offline applications' shortcuts in web pages; maybe they're not the best, since they suffer for a double dependence, from the browser settings and the underlying operating system settings. So, if you even could make modifiers consistent from one browser to another on the same platform, you couldn't easily do the same cross-platform. Yet the overall mechanism might be improved. One way to achieve this could be using key events, to create a more articulate environment, and (anyway) establishing a generic reference to a browser default modifiers (the ones provided for accesskeys) could be usefull for cross-browser, cross-platform consistence (perhaps even for your purposes). For the rest, do you want to develope a browser (or a browser to be developed) with the option to bypass default accesskeys at the user will? That's possible, even without a direct support by the html: just add this option and make it working like any other browser customization, then store somewhere the users' choices on a somewhat profile. Do you want generic commands, like mouse-keys combinations, or mouse gestures too? That's the same, all to do is intercepting the command before the document and translate it into an activation of the desired control (i.e., by generating the activation behavior as defined in section 3.4.1.7 Interactive content). Do you wish to exchange the profile between browsers? Well, perhaps you're asking for a common profile format and a shared local storage among browsers... uhm, no, that would fail cross-platform (i.e. using a different OS or a different computer), so another solution should be found... perhaps storing users' webapps profiles in a remote server could solve such, and new services could start around such possibility, but perhaps that could lead to some security concerns, and perhaps, at the moment, it could be better to leave to each site developers the choice of default keybindings and the implementation of a mechanism to let the user customize the site/the webapp, storing the user's choices either locally or remotely on the site/the webapp server. Maybe a future version of html could endorse support for such (if not convenient at the moment). Perhaps an element could have an activators attribute holding the id of an activatorset element, which could be something like, activatorset id=foo sequence type=keys key type=identifier state=down value=a_unicode_value_here / key type=modifier state=down value=defaultModifiers; / !-- a state of 'down' stands for a contemporary pression, regardless the order of items declaration, and there can be any order for releasing pressed keys, but after the first release (state=up), any other pression must happen after the released key - or mouse button -- key type=special state=down value=arrow_left; / key type=any state=up / !-- when every declared item is released, the command fires and synthetic click activation steps are run, perhaps adding an activation event carrying the proper sequence of keys and mouse actions, so the developer can choose among handling the (sinthetic) click, the activation event or the DOMActivate event -- /sequence!-- the first activation sequence is defined, any other is an alternative way to activate a control -- sequence type=mouse mousebutton type=left state=down / mousebutton type=right state=down / !-- here state has the same meaning of above: users can press them contemprary, or one first, then the other while still holding the other down -- mousebehaviour type=move-right / mousebehaviour type=wheel value=-3 / !-- mouse behaviours should happen in order, however the
Re: [whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?]
timeless wrote: Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Ultimately, a user agent or user can always reject presentational fluff. designing a user interface to enable users to tell their user agent to ignore such content ends up being more complicated and problematic than supporting the feature. for people w/ limited abilities, needing to spend any realestate or access option to disable a feature which will most often be abused and explain to users how and when and why to disable or enable it is expensive. Are you essentially saying it requires (expensive) user effort to disable features that interfere with their consumption of content or their use of an application? This is true, but it's not a particularly persuasive argument given just how many features in the web stack can cause people problems. Consider how frequently visual CSS is abused, when the category of abuse includes accidentally making things harder to use for people with certain disabilities. I think you'll find such abuse is somewhere between commonplace and endemic, e.g. disabling of the focus ring for aesthetic reasons, hiding of focusable content, CSS image replacement hacks, tiny text, poor color contrast, unusual widget styling, pure CSS dropdown menus that only work with the mouse, use of styling as a substitute for media-independent markup, etc. (That's not an argument that such practices are okay; it's just to observe that they aren't generally taken as a knockdown argument against supporting visual CSS.) And, as it happens, many popular user agents do, in fact, give people a reasonably simple UI for rejecting publisher styles (Opera and Firefox among them). -- Benjamin Hawkes-Lewis
Re: [whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?]
i don't really want to spend a lot of time with this, but any feature authors are provided will be abused. among my list of things which i wish were never let out of pandora's box are defining accesskeys (instead of commands) in html, and another which i'd hope dies on the vine is aural css. sure it is theoretically nice to let someone encode audio. however on average it's going to be used more often by advertisers than actual content developers. the amount of effort required to invest in a feature which is generally not useful far exceeds any value offered to the user by the agent. in the case of accesskeys, a much more useful research area is to developer a browser global way of accessing content which works well for the device/useragent/user. enabling each site to design its own poor access keys is much less useful than letting browsers be configured by their users or share keybindings from one browser to another for a given site. in the case of aural css, the screen reader user agents have clearly reviewed the mistakes of prior features and i congratulate them on their decision not to invest in this area. not all technology is good or useful. some technology thankfully does fail (p3p comes to mind, although it seems that POWDER wants to try again).
Re: [whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?]
Benjamin Hawkes-Lewis ha scritto: Calogero Alex Baldacchino wrote: That worked fine on Opera 9 and FF2, but, when tried on IE7, the show became a little weird... the element was there, the style attribute was regarded as for any other element (display:block worked), but didn't applied to any of its descendents, as if they weren't its descendents... setting 'display:inline' didn't changed much but a brake in the line disappeared, *setting 'display:none' didn't made any descendent disappear... Why? Note that display values cascade, but do not inherit: http://www.w3.org/TR/CSS21/visuren.html#propdef-display http://www.w3.org/TR/CSS21/cascade.html#inheritance From the first link: none This value causes an element to generate *no* boxes in the formatting structure (i.e., the element has no effect on layout). Descendant elements do not generate any boxes either; this behavior *cannot* be overridden by setting the 'display' property on the descendants. Basically, an element (with 'normal' positioning, at least) should create its own box inside its parent box, but if the paren't box doesn't exist, the child cannot have a box as well, so there is no need to make the display value inheritable in order to make descendant elements 'disappear' from the formatting structure. The inheritance, instead, could cause problems (unwanted behaviors) for floating elements and elements positioned outside the normal flow, so it couldn't be the default value (such is clarified in http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo : If 'display' has the value 'none', then 'position' and 'float' do not apply. In this case, the element generates no box.). The 'problem', with IE, is its way to treat an unknown element, which cannot have children, so cascading and inheritance fail. This leads to the need for scripting solution along with fallback styles, and perhaps compromises the usefulness of a foundation style sheet for legacy user agents (at least, that wouldn't work alone). Though, a uniform default layout for visual user agents could be desireable. Perhaps, if a foundation default aural sheet had been provided from its early standard definition, assistive addons could have choosen to support aural CSS, since the base would have been good and all they had to do would have been treating values as relative ones, to adjust accordingly to their usability studies... Well, there was at least: http://www.w3.org/TR/CSS2/sample.html -- Benjamin Hawkes-Lewis You see, I don't feel to agree with the reasons at the base of developers choice to ignore aural CSS, because granting to the user ( = the listener) or to the software ( = the screan reader) an exclusive full control upon speach constraints cannot be the best way to make the spoken message more understandable, because the author of the (written) message is the only one who really knows its real meaning, and since we understend a spoken message by the way it's... spoken, no one can know how to render aurally a message meaning better then its author. I guess a non-expert author could have made evrithing unintelligible, but I think a good occasion has been underestimated from several points of view... For instance, widespreading aural support could have leaded to an integration of speech engines in authoring tools, perhaps the same used by screen readers (especially in commercial authoring tools); maybe the tool could have taken a registration of the author reading a page to compare it to the way the speech engine read the same page and suggest correct settings for pitch, speed, volume, averaging between the autor reading and the engine usability constraints... But I know (and agree with Pentasis) any aural-style related subject is a marginal discussion in the scope of HTML. BR, Alex -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Personalizza il tuo cellulare con tantissimi temi! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8275d=28-11
Re: [whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?]
Calogero Alex Baldacchino wrote: That worked fine on Opera 9 and FF2, but, when tried on IE7, the show became a little weird... the element was there, the style attribute was regarded as for any other element (display:block worked), but didn't applied to any of its descendents, as if they weren't its descendents... setting 'display:inline' didn't changed much but a brake in the line disappeared, *setting 'display:none' didn't made any descendent disappear... Why? Note that display values cascade, but do not inherit: http://www.w3.org/TR/CSS21/visuren.html#propdef-display http://www.w3.org/TR/CSS21/cascade.html#inheritance having a closer look to the element's properties you can note a 'canHaveHTML' property with a value of 'false', while both firstChild and lastChild are null. It seems the unknown element is treated as expected, but any markup between its opening and closing tags is moved outside... That mean, for instance, trying and hiding a menu element which is a context menu would not work with its list of items, while floating it if it was a sidebar would not float its inner elements as well... There is certainly a backwards compatibility issue with how unknown elements are parsed, although there is a JS-dependent hack to fix IE7: http://blog.whatwg.org/the-road-to-html-5-episode-1-the-section-element A similar problem and hack exists for styling HTML4's ABBR in IE6 too. Perhaps, if a foundation default aural sheet had been provided from its early standard definition, assistive addons could have choosen to support aural CSS, since the base would have been good and all they had to do would have been treating values as relative ones, to adjust accordingly to their usability studies... Well, there was at least: http://www.w3.org/TR/CSS2/sample.html -- Benjamin Hawkes-Lewis
Re: [whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?]
Benjamin Hawkes-Lewis ha scritto: Calogero Alex Baldacchino wrote: I know, and agree with the basic reasons; however I think that deriving an SGML version (i.e. by adding new entities and elements, as needed, to an html 4 dtd) should not be very difficoult, and could be worth the effort (i.e. to graceful degrade the presentation of a menu element thought as a context menu, wich content should not be shown untill a right click happens - if the u.a. cannot handle it, not showing it at all could be a reasonable behaviour). The derived sgml version should be aimed just for older browsers, while newer, html 5-aware ones should just ignore any dtd reference. I'd consider this chance, at least on the fly - I suspect that the complete break out with the earlier sgml specifications might carry in an undesireable side-effect: from one side it solves the problems arised from sgml partial support/bad implementation and from browser-specific quirks, but from the other side no mechanism is provided to make sgml-somehow-based user agents to gain whatever awareness on the newly defined elements. What SGML-somehow-based user agents? While many web browsers switch behavior based on what they detect in the first characters of an HTML document (including the doctype declaration), there are no (or at any rate, no remotely /popular/ web browsers) that read text/html DTDs in the way required for this idea to be workable. Since all you're proposing is to bake implied STYLE values into the DTD, it seems to me your use-case could be served by making an HTML5 foundation stylesheet publicly available. Compare: http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/ http://developer.yahoo.com/yui/base/ -- Benjamin Hawkes-Lewis Oh, I thought (and hoped) a somewhat basic support were provided... I understand I was wrong... The foundation style sheet may be at least a partial solution, but if the browser is not aware of an element, I guess its style could not apply at all. Anyway, a standard default style sheet could be desireable both to have a standard basic layout on all browsers (as far as possible, because of possible differences in CSS compliance) and as a potential aid for assistive UAs, since the default sheet could cover a few basic aureal properties. Regards, Alex -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: A fine mese devi affrontare molte spese? Intesa Sanpaolo ti parla di Check-up finanziario. Prenotalo qui senza impegno Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8436d=26-11
Re: [whatwg] Fallback styles for legacy user agents [was: Re:
From: Calogero Alex Baldacchino [EMAIL PROTECTED] Subject: Re: [whatwg] Fallback styles for legacy user agents [was: Re: Deprecating small , b ?] To: Benjamin Hawkes-Lewis [EMAIL PROTECTED] Cc: WHAT Working Group whatwg@lists.whatwg.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed The foundation style sheet may be at least a partial solution, but if the browser is not aware of an element, I guess its style could not apply at all. Anyway, a standard default style sheet could be desireable both to have a standard basic layout on all browsers (as far as possible, because of possible differences in CSS compliance) and as a potential aid for assistive UAs, since the default sheet could cover a few basic aureal properties. Regards, Alex Not too long ago I needed to provide a special section for a website which was only accessible to users of screenreaders. I collaborated with users from windows-eyes and JAWS (the 2 screenreaders with the biggest custumer-base). I got myself some trieal versions and started testing and talking... Guess what, aural styles are ignored by screenreaders (they were a year and a half ago and I am assuming they are now). I contacted one of the manufactureres and I am sorry I can't remember which one, I think it was JAWS but it could have been Windows-eyes. After a lengthy correspondance they told me what basically comes down to this: They do not support aural style sheets because they don't want us (authors) to take control away from the users. They say it is too confusing and basically non-accessible when we (authors) change voice, pitch, volume, etc. Well, in that area I can agree with them. Screenreaders are very personal tools I gather from users. Basically it is a bad idea to mark-up aural properties when it comes to accessibility. However, it would still be nice to hide/show things solely for specific UAs. But just because CSS gives us the ability to use extensive aural properties is exactly why they don't want to gice us the ability to hide/show things. Again, this information is well over a year old, so maybe they have changed policies. Still I think it is unwise to include aural properties in style sheets, default or otherwise. We must let the users choose their volume, speed, pitch, voice, etc. because that is what is helping them most (this is what I have been told by manufacturer and users). I know it is a side-issue on this topic (and has little to do with HTML) but since you mention it as an argument I just thought it might be relevant. Bert
Re: [whatwg] Fallback styles for legacy user agents [was: Re:
Pentasis wrote: Basically it is a bad idea to mark-up aural properties when it comes to accessibility. It does not follow from the fact that popular screen readers ignore publisher aural/speech CSS or the reasonable argument that they _should_ ignore such CSS, that providing publisher aural/speech CSS is bad for accessibility. For example, if you want to put a novel online with aural/speech CSS so it can be read aloud by Opera with the Voice plugin with those styles, there's no reason why that's bad for accessibility. It just means that providing aural/speech CSS doesn't do what well-meaning web developers sometimes imagine it should. However, it would still be nice to hide/show things solely for specific UAs. Maybe, but I wonder if in practice, the rationales for this tend to boil down to: 1. Working around bugs in someone's code. (e.g. A screen reader fails to deal with Feature X in a webpage, so the developer inserts a message for screen reader users describing a workaround.) 2. A workaround for supporting non-linear, non-gestalt browsing (e.g. additional context for lists of links in a screen reader). There may be more direct and effective ways to deal with these problems, such as * Making product support information available to all users (what if the screen reader user has a sighted companion? What if they're using a screen magnifier/reader combination?) * Fixing browsers and screen readers. * Providing explicit markup for additional context. -- Benjamin Hawkes-Lewis
