[whatwg] Fallback styles for legacy user agents [was: Re: Deprecating <small> , <b> ?]
Calogero Alex Baldacchino
alex.baldacchino at email.it
Fri Nov 28 05:56:51 PST 2008
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:
From the first link:
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:
> 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.
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Personalizza il tuo cellulare con tantissimi temi!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8275&d=28-11
More information about the whatwg