Closed Bug 294277 Opened 20 years ago Closed 20 years ago

Support 'inline' <alert>s

Categories

(Core Graveyard :: XForms, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: smaug, Assigned: smaug)

Details

Attachments

(2 files)

patch coming
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; }
Attachment #183659 - Flags: review?(aaronr)
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.
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.
(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.
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?
(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 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.
Attachment #183659 - Flags: review?(aaronr) → review+
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?
Attachment #183659 - Flags: review?(doronr)
Attachment #183659 - Flags: review?(doronr) → review+
With XBL we may have to re-think how this should/could work, but for now, checked in, fixed
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: