- From: Calogero Alex Baldacchino <alex.baldacchino@email.it>
- Date: Fri, 28 Nov 2008 14:56:51 +0100
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=8275&d=28-11
Received on Friday, 28 November 2008 05:56:51 UTC