[whatwg] Fallback styles for legacy user agents [was: Re: Deprecating <small> , <b> ?]
Calogero Alex Baldacchino
alex.baldacchino at email.it
Thu Nov 27 12:00:57 PST 2008
Benjamin Hawkes-Lewis ha scritto:
> Calogero Alex Baldacchino wrote:
>> 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.
> For popular browsers, at least, this guess is wrong. Unknown elements
> are commonly added to the Document Object Model and subject to styling.
I've tried the following:
<title>Testing the stile of an unknown-markup element</title>
<p>This is a... <giraffe style="display:block; font-size: 14pt;
font-weight: bold; font-style: oblique;">What's this? <a
link');">second link</a> </giraffe> Let's have a look...</p>
var test = document.getElementsByTagName("giraffe").item(0);
var str = "";
for(prop in test)
str += "The element has the property: <b>" +
"</b> with the value: <b>" +
test[prop] + "</b><br />";
(perhaps not much readeble on an email...)
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? 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
>> 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.
> There is a little support for aural/speech CSS: Opera for Windows with
> the Voice plugin, the Emacs/W3 and Emacspeech addons for the Emacs
> environment, the FireVox extension for the Firefox browser. None of
> these seem to be in widespread use.
Well, this could change in the future, who knows...
> I'm not aware of any implementation
> support for the braille or proposed reader media types. But, yes, a
> foundation stylesheet could certainly cater to these.
> Benjamin Hawkes-Lewis
And could be an help to avoid messing up the authors' sheets, being a
start point (perhaps using relative values to modify the default).
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...
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Gioca e vinci con Sheba!
* Partecipa a concorso "I sensi di un'intesa perfetta" vinci fantastici premi per il tuo gatto!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8433&d=27-11
More information about the whatwg