294277 - Support 'inline' <alert>s

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

patch coming

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Attachment: patch, based on XTF, not XBL

Aaron, is this what you want? I can't test Novell's plugin
because it crashes immediately :(

This should work now (but also the old alert popups work):

@namespace xf url("http://www.w3.org/2002/xforms");
xf|*[valid] xf|alert {
  display: none;
}
xf|*[invalid] xf|alert {
  display: inline;
  color: red;
}

Comment 2

[aaronr]

Attachment: .png pict of this patch vs. Novell plugin

Here is a .png file that shows the difference between Mozilla's behavior with
smaug's patch and the behavior that Novell's plugin has.

Comment 3

[aaronr]

pretty close to what Novell has.  But they put the alert before the form element
(and any contained labels).  If you'll notice the .png, in your patch the alert
almost wraps around the control.  It would be nice if the alert text were in a
column, the label text is in a column, and the control is in the third column. 
Like Novell does it.

I'm not convinced, though, that before the label is the best place for the alert
since it isn't right next to the control.  If the css weren't styled so that the
whole row were highlighted, it wouldn't be obvious to me that the alert goes
with the control.  But I am no UCD expert and I don't feel particularly adament
either way.  As long as the alert, label and control don't flow into each other,
I don't really mind where the alert goes relative to the other two.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #2)
> Created an attachment (id=183669) [edit]
> .png pict of this patch vs. Novell plugin
> 
> Here is a .png file that shows the difference between Mozilla's behavior with
> smaug's patch and the behavior that Novell's plugin has.

the <alert> could be the first child of <input>, then it would be rendered
before <label>. 
I don't have the test case now in front of me, be afair it was/is using
display:inline;width:XXpx; for the <alert>. That works only on IE.
It should not, because width doesn't apply to inline boxes.

Comment 5

[aaronr]

Alert can't be the first child of input since label has to be according to the
schema.  I think that if the user does float:right with the alert that it looks
pretty good, though -> makes the alert sit to the right of the control.

Why do you still display the alert as a popup if the style says display:none? 
That doesn't seem right.  Shouldn't that be a way for a author to keep alerts
from popping up at all?

In nsXFormsModelElement::SetSingleState you move DispatchEvent to after the
attribute set and removal, but I don't see anything in your code that requires
the attributes to be set.  Is this to fix another problem?

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #5)
> In nsXFormsModelElement::SetSingleState you move DispatchEvent to after the
> attribute set and removal, but I don't see anything in your code that requires
> the attributes to be set.  Is this to fix another problem?

Otherwise checking display:none wouldn't work, because the style of the element
hasn't been changed yet.

Comment 7

[aaronr]

Comment on attachment 183659 [details] [diff] [review]
patch, based on XTF, not XBL

I talked with smaug about why display:none is the default and he said that it
is needed as the default value to ward of potential style inheritance problems.
 Also the fact that if the form author doesn't declare a 'display:'style rule
then display:inline is returned when style is queried.	So we declare
display:none as the default.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 183659 [details] [diff] [review]
patch, based on XTF, not XBL

>potential style 
>inheritance problems
I wouldn't call those problems. That is the way CSS works ;)

Anyway, perhaps doron can r?

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

With XBL we may have to re-think how this should/could work, 
but for now, checked in, fixed