Re: [whatwg] usemap= and related issues
Jonas Sicking wrote: Ian Hickson wrote: On Thu, 26 Jun 2008, Jonas Sicking wrote: What I did notice in our code though is how we deal with the case when there are multiple maps with the same name. In this case we generally use the first map. But if the first map is empty, we use the first non-empty map. This was done for compatibility with some sites. See https://bugzilla.mozilla.org/show_bug.cgi?id=264624 I have no idea if this matters today or not. I couldn't reproduce this behavior. Try the following markup in firefox: map name=foo/map map name=foo area shape=circle coords=10,10,10 href=http://www.mozilla.com; /map img src=http://www.mozilla.org/images/feature-logos1.png; usemap=#foo width=20 height=20 This only seems to occur in quirks mode, not in standards mode. But neither Opera, Safari or IE8 have the same behaviour. Additionally, the site reported in the bug you mentioned no longer suffers from the bug. Therefore, it doesn't appear to be necessary that we should require that behaviour. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
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] accesskey attribute with display:none elements
Olli Pettay ha scritto:
On 11/27/2008 06:52 PM, Calogero Alex Baldacchino wrote:
Perhaps a *good* rationale could be, if you can't see the control,
There are other modalities than just visual.
Indeed, and the display property applies to every and each the very same
way. From http://www.w3.org/TR/CSS21/visuren.html#propdef-display
'display'
Value: inline | block | list-item | run-in | inline-block | table
| inline-table | table-row-group | table-header-group |
table-footer-group | table-row | table-column-group | table-column |
table-cell | table-caption | none | inherit
Initial:inline
Applies to: all elements
Inherited: no
Percentages:N/A
*Media: all*
If you care of any media aving trouble with 'display:none' (and might be
for a visual browser + a screen reader), you have to change the value
for that media. But if one can afford to write different style sheets
for different media, one can also afford to avoid 'display:none' at all
when it comes to interaction, and instead emulate it by setting a bounch
of other properties so that the element occuped 1px or so, without
affecting heavily the overall visual layout, and without problems with
non-visual media (but there is another possibility, yet working only
with css 2 compliant browsers: a menu can have an absolute positioning,
or being floating, and a zindex telling if it's in front of or behind
another element, which in turn can be opaque, so switching the zindex
could work as fine as switching the display property).
So, I stand up for
standardizing the disallow accesskey activation for 'display:none'
elements behaviour.
So you're willing to break accesskeys on some websites.
HTML *5* is the next evolution of HTML, that means it's almost a new
language looking backward with one eye and forward with the other,
carrying on something from the past and throwing away somthing else,
finding some compromises for the transition phase. I think that hiding
something to the user (whatever is the presentation modality), as if
that wasn't in the document at all ('display:none' as a stronger
semantics than just being hidden, invisible, behind something, and so
on), but expecting the user would interact with that, is not the best
possible practise, and since, as far as I remember, there have never
been assurances on good working of accesskeys, a break with old,
non-standard behaviours could not be a murderer. But, however...
Note, I'm not very strongly supporting accesskeys on display:none elements,
but breaking existing web sites doesn't sound good.
-Olli
but the question could be another. The new behaviour of FF3 breaks
compatibility with existing HTML *4* (or xhtml) sites, without being an
HTML *5* *only* browser (perhaps, at some point in the future, html 5
could become the 'older' backward compatibility basis, like today
browsers provide older features, i.e. document.all or document.layer,
along with newer DOM features), so that break, though not being in
contrast with any standard, could be deemed a kind of bug. My point now
is: let's state *HTML 5* elements cannot be activated through accesskeys
when they have a display propery of 'none', but user agents are left
free (after all that's never been a standard) to activate non-HTML 5
elements with the property 'display:none' for backward compatibility.
That should mean the old, non-standard behaviour could be turned on for
existing websites just by adding a dtd reference in the doctype
declaration. Does it sound acceptable at you?
Regards, Alex.
--
P.S. I take it separate because off topic, but I'd really consider
something like,
HTMLKeybordEvent{
readonly boolean attribute activationModifiers;
}
independent from generic DOM keyboard events, yet easily bindable to
them and quite safe from changes in DOM 3 Events Working Draft.
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Scegli la tua suoneria! Il meglio della musica sul tuo cellulare!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8269d=28-11
Re: [whatwg] comment on autofocus attribute from Web Forms 2.0 spec
On Sat, 08 Nov 2008 18:46:48 +0100, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 16 Jun 2008, Adele Peterson wrote: I saw the need for this in our Web Inspector, which has a lot of custom controls (including some that use contenteditable elements). Some of these don't have a default focused appearance, but its nice that they can follow the focus pseudo-class CSS selector. I agree that the disabled attribute would fit in well with this. Again, it would be nice for these custom controls to be able to use the disabled pseudo-class CSS selector. I really would rather see XBL2's div element be extended to be focusable and disablable rather than have HTML support this. Does that make sense? How would you disable td contenteditable or div contenteditable with that strategy and have td:disabled and div:disabled (or something very close to it) work? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
