Closed
Bug 336305
Opened 18 years ago
Closed 8 years ago
Warn if instance document is in xhtml/svg/xul namespace?
Categories
(Core Graveyard :: XForms, enhancement)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: doronr, Unassigned)
Details
For XForms newbies, the first issue they hit seems to be not giving inline instance documents a namespace, so the document goes into the parent's, and usually that will break xpath expressions. Perhaps, when we load instances into documents, we should warn if the namespace is a common host one, like xhtml/svg/xul?
Reporter | ||
Comment 1•18 years ago
|
||
oops, wrong cc:
Comment 2•18 years ago
|
||
(In reply to comment #0) > For XForms newbies, the first issue they hit seems to be not giving inline > instance documents a namespace, so the document goes into the parent's, and > usually that will break xpath expressions. > > Perhaps, when we load instances into documents, we should warn if the namespace > is a common host one, like xhtml/svg/xul? Although on theory I have something against doing stuff like this, in practice this is _so_ common an error that it would probably be nice. Especially since it should only incur extra work pr. inline instance on form load. I would like to have it packed inside a pref. though.
(In reply to comment #2) > (In reply to comment #0) > > For XForms newbies, the first issue they hit seems to be not giving inline > > instance documents a namespace, so the document goes into the parent's, and > > usually that will break xpath expressions. > > > > Perhaps, when we load instances into documents, we should warn if the namespace > > is a common host one, like xhtml/svg/xul? > > Although on theory I have something against doing stuff like this, in practice > this is _so_ common an error that it would probably be nice. Especially since > it should only incur extra work pr. inline instance on form load. I would like > to have it packed inside a pref. though. Well, if we leave it as a WARNING and not an error, then the user can already filter out warnings via the JS Console. If we guard it by a pref, then I assuem that we'd have the warnings on by default and allow them to be turned off by a pref? That might not be so bad. But if they were off by default and you had to turn them on by a pref then I dunno. This is to help the newbies afterall, and turning on and off prefs isn't something they'd probably look for. But I don't have strong feelings either way, really.
Comment 4•18 years ago
|
||
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > For XForms newbies, the first issue they hit seems to be not giving inline > > > instance documents a namespace, so the document goes into the parent's, and > > > usually that will break xpath expressions. > > > > > > Perhaps, when we load instances into documents, we should warn if the namespace > > > is a common host one, like xhtml/svg/xul? > > > > Although on theory I have something against doing stuff like this, in practice > > this is _so_ common an error that it would probably be nice. Especially since > > it should only incur extra work pr. inline instance on form load. I would like > > to have it packed inside a pref. though. > > Well, if we leave it as a WARNING and not an error, then the user can already > filter out warnings via the JS Console. If we guard it by a pref, then I > assuem that we'd have the warnings on by default and allow them to be turned > off by a pref? That might not be so bad. But if they were off by default and > you had to turn them on by a pref then I dunno. This is to help the newbies > afterall, and turning on and off prefs isn't something they'd probably look > for. But I don't have strong feelings either way, really. On by default. I just do not like us to emit stuff on the console, when nothing is actually wrong. That's all.
Updated•18 years ago
|
Assignee: aaronr → xforms
Comment 5•8 years ago
|
||
RIP xforms
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•