21 Sep
2010
21 Sep
'10
12:44 p.m.
I've made some additions to our Forms Standard page:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms
The standard is very similar to what we have for the WYSIWYG editor:
- vertical alignment
- display of labels (we have uppercase text for Colibri style consistency)
- display of hints/error messages
- primary/secondary buttons
I made a proposal to integrate this standards inside the platform:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal
- administration
- object editor
- user profile
- Create Space/Page
- Copy/Rename Page
Any feedback is welcomed,
Caty
21 Sep
21 Sep
2:18 p.m.
Hi Cati,
On Tue, Sep 21, 2010 at 12:44, Ecaterina Valica <valicac(a)gmail.com> wrote:
I've made some additions to our Forms Standard
page:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms
The standard is very similar to what we have for the WYSIWYG editor:
- vertical alignment
- display of labels (we have uppercase text for Colibri style consistency)
- display of hints/error messages
- primary/secondary buttons
I made a proposal to integrate this standards inside the platform:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal
- administration
- object editor
- user profile
- Create Space/Page
- Copy/Rename Page
Any feedback is welcomed,
Looks good, I like it. The sum of little details like this will eventually
make XWiki feel even more polished and professional, which is good.
Nice job :-)
Guillaume
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:53 p.m.
Looks very nice as usual except that I'm not a big fan of uppercase.
On Tue, Sep 21, 2010 at 12:44, Ecaterina Valica <valicac(a)gmail.com> wrote:
I've made some additions to our Forms Standard
page:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms
The standard is very similar to what we have for the WYSIWYG editor:
- vertical alignment
- display of labels (we have uppercase text for Colibri style consistency)
- display of hints/error messages
- primary/secondary buttons
I made a proposal to integrate this standards inside the platform:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal
IMO the most important things before even deciding the standard is to
provide commons tools to follow that standard (like form related wiki
macros for example). Then you can change it all you want but
everything will stay consistent consistent.
- administration
- object editor
- user profile
- Create Space/Page
- Copy/Rename Page
Any feedback is welcomed,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
5:35 p.m.
On 09/21/2010 03:53 PM, Thomas Mortagne wrote:
Looks very nice as usual except that I'm not a big
fan of uppercase.
Same here, not a big fan of upper case labels. Otherwise the forms look
great! Well done!
Thanks,
Marius
On Tue, Sep 21, 2010 at 12:44, Ecaterina Valica<valicac(a)gmail.com> wrote:
I've made some additions to our Forms
Standard page:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms
The standard is very similar to what we have for the WYSIWYG editor:
- vertical alignment
- display of labels (we have uppercase text for Colibri style consistency)
- display of hints/error messages
- primary/secondary buttons
I made a proposal to integrate this standards inside the platform:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal
IMO the most important things before even deciding the standard is to
provide commons tools to follow that standard (like form related wiki
macros for example). Then you can change it all you want but
everything will stay consistent consistent.
- administration
- object editor
- user profile
- Create Space/Page
- Copy/Rename Page
Any feedback is welcomed,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:40 p.m.
On Tue, Sep 21, 2010 at 18:35, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 09/21/2010 03:53 PM, Thomas Mortagne wrote:
bold.
Looks very nice as usual except that I'm not
a big fan of uppercase.
Same here, not a big fan of upper case labels. Otherwise the forms look
great! Well done!
The uppercase is because that's Colibri style. Otherwise they should be Thanks,
Marius
Macros idea is very nice. Also we will need to standardize the CSS classes
(just like the buttonwrapper one).
Thanks,
Caty
On Tue, Sep 21, 2010 at 12:44, Ecaterina Valica<valicac(a)gmail.com>
wrote:
> I've made some additions to our Forms
Standard page:
> http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms
>
> The standard is very similar to what we have for the WYSIWYG editor:
> - vertical alignment
> - display of labels (we have uppercase text for Colibri style
consistency)
- display
of hints/error messages
- primary/secondary buttons
I made a proposal to integrate this standards inside the platform:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal
IMO the most important things before even deciding the standard is to
provide commons tools to follow that standard (like form related wiki
macros for example). Then you can change it all you want but
everything will stay consistent consistent.
- administration
- object editor
- user profile
- Create Space/Page
- Copy/Rename Page
Any feedback is welcomed,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8 Oct
8 Oct
11:17 p.m.
Hi,
I've made a more complete description of the classes that need to be
integrated to comply with the standard:
[New] Forms Usage:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormVerticalUsage
-------------------------------------------------------------------------------------------------------------------------------------
[Old] Forms Standard:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms
Integration Proposal:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal
Thanks,
Caty
9 Oct
9 Oct
9:53 a.m.
On 10/09/2010 12:17 AM, Ecaterina Valica wrote:
Hi,
I've made a more complete description of the classes that need to be
integrated to comply with the standard:
[New] Forms Usage:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormVerticalUsage
I'd like to see this put into practice. Well done!
Thanks,
Marius
-------------------------------------------------------------------------------------------------------------------------------------
[Old] Forms Standard:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms
Integration Proposal:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal
Thanks,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11 Oct
11 Oct
12:39 p.m.
Hi,
Subject: [Form Buttons: Input vs. Link]
In XWiki we have buttons that are created using input-submit || input-button
|| <a and the CSS is trying to have the same style for inputs and links,
even thought is quite difficult (native browser rules differ from case to
case and there are inconsistencies, like
http://jira.xwiki.org/jira/browse/XSCOLIBRI-234 ) and semantically they have
different functions. We also have some problems when representing the
buttons, because buttons should be 3D, having the affordance that you can
push them, but that's another story.
So I want to know if there is a special technical reason (JS related? is
more simple to listen to <a?) why we have links and inputs for form submit
actions, or we could use only inputs and make this a standard.
Thanks,
Caty
Read more: http://www.uxbooth.com/blog/creating-usable-links-and-buttons/
1:37 p.m.
Hello,
Using buttons is mandatory for the cases where JavaScript is disabled.
That's because by default a form can be submitted only through an
input of type 'submit'. Links are usually used for redirecting to
another page, not for submitting the form.
I think that for form actions we should use inputs, not links.
Raluca.
On Mon, Oct 11, 2010 at 1:39 PM, Ecaterina Valica <valicac(a)gmail.com> wrote:
Hi,
Subject: [Form Buttons: Input vs. Link]
In XWiki we have buttons that are created using input-submit || input-button
|| <a and the CSS is trying to have the same style for inputs and links,
even thought is quite difficult (native browser rules differ from case to
case and there are inconsistencies, like
http://jira.xwiki.org/jira/browse/XSCOLIBRI-234 ) and semantically they have
different functions. We also have some problems when representing the
buttons, because buttons should be 3D, having the affordance that you can
push them, but that's another story.
So I want to know if there is a special technical reason (JS related? is
more simple to listen to <a?) why we have links and inputs for form submit
actions, or we could use only inputs and make this a standard.
Thanks,
Caty
Read more: http://www.uxbooth.com/blog/creating-usable-links-and-buttons/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:50 p.m.
On 10/11/2010 12:39 PM, Ecaterina Valica wrote:
Hi,
Subject: [Form Buttons: Input vs. Link]
In XWiki we have buttons that are created using input-submit || input-button
||<a and the CSS is trying to have the same style for inputs and links,
even thought is quite difficult (native browser rules differ from case to
case and there are inconsistencies, like
http://jira.xwiki.org/jira/browse/XSCOLIBRI-234 ) and semantically they have
different functions. We also have some problems when representing the
buttons, because buttons should be 3D, having the affordance that you can
push them, but that's another story.
So I want to know if there is a special technical reason (JS related? is
more simple to listen to<a?) why we have links and inputs for form submit
actions, or we could use only inputs and make this a standard.
Thanks,
Caty
Normally, all the buttons should be <input type="submit">, but:
- There are some old applications or templates that use <button
onclick>, which is extremely wrong for accessibility, and thus this
should never be used, and all the existing instances should be fixed.
- Some buttons are done with links, since their action is not a submit
action. I'm talking about most Cancel buttons, which shouldn't send the
form content back to the server. Implementing them as submitinput will
send the form content to the server. Sending the form content to the
server means more transfer time (sending bytes through the network),
more memory and processing time (allocating memory for holding the
request data, allocating time for processing the request).
So, I think that we do have to maintain two kinds of buttons:
submitinput, and ahref.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
2:08 p.m.
Hello,
I belive using <button> is also a good idea, since this tag works and behave
in exactly the same way as <input>. The advantage of the <button> is that we
can put content inside of it like text or images (icons).
Thanks,
Ciprian.
On Mon, Oct 11, 2010 at 2:50 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 10/11/2010 12:39 PM, Ecaterina Valica wrote:
--
Ciprian,
Designer
XWiki
Hi,
Subject: [Form Buttons: Input vs. Link]
In XWiki we have buttons that are created using input-submit ||
input-button
||<a and the CSS is trying to have the same
style for inputs and links,
even thought is quite difficult (native browser rules differ from case to
case and there are inconsistencies, like
http://jira.xwiki.org/jira/browse/XSCOLIBRI-234 ) and semantically they
have
different functions. We also have some problems
when representing the
buttons, because buttons should be 3D, having the affordance that you can
push them, but that's another story.
So I want to know if there is a special technical reason (JS related? is
more simple to listen to<a?) why we have links and inputs for form submit
actions, or we could use only inputs and make this a standard.
Thanks,
Caty
Normally, all the buttons should be <input type="submit">, but:
- There are some old applications or templates that use <button
onclick>, which is extremely wrong for accessibility, and thus this
should never be used, and all the existing instances should be fixed.
- Some buttons are done with links, since their action is not a submit
action. I'm talking about most Cancel buttons, which shouldn't send the
form content back to the server. Implementing them as submitinput will
send the form content to the server. Sending the form content to the
server means more transfer time (sending bytes through the network),
more memory and processing time (allocating memory for holding the
request data, allocating time for processing the request).
So, I think that we do have to maintain two kinds of buttons:
submitinput, and ahref.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:12 p.m.
Thanks for your answers, it's clear now.
Caty
On Mon, Oct 11, 2010 at 14:50, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 10/11/2010 12:39 PM, Ecaterina Valica wrote:
Hi,
Subject: [Form Buttons: Input vs. Link]
In XWiki we have buttons that are created using input-submit ||
input-button
||<a and the CSS is trying to have the same
style for inputs and links,
even thought is quite difficult (native browser rules differ from case to
case and there are inconsistencies, like
http://jira.xwiki.org/jira/browse/XSCOLIBRI-234 ) and semantically they
have
different functions. We also have some problems
when representing the
buttons, because buttons should be 3D, having the affordance that you can
push them, but that's another story.
So I want to know if there is a special technical reason (JS related? is
more simple to listen to<a?) why we have links and inputs for form submit
actions, or we could use only inputs and make this a standard.
Thanks,
Caty
Normally, all the buttons should be <input type="submit">, but:
- There are some old applications or templates that use <button
onclick>, which is extremely wrong for accessibility, and thus this
should never be used, and all the existing instances should be fixed.
- Some buttons are done with links, since their action is not a submit
action. I'm talking about most Cancel buttons, which shouldn't send the
form content back to the server. Implementing them as submitinput will
send the form content to the server. Sending the form content to the
server means more transfer time (sending bytes through the network),
more memory and processing time (allocating memory for holding the
request data, allocating time for processing the request).
So, I think that we do have to maintain two kinds of buttons:
submitinput, and ahref.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:52 p.m.
Sounds good to me.
Thanks
-Vincent
On Sep 21, 2010, at 12:44 PM, Ecaterina Valica wrote:
I've made some additions to our Forms Standard
page:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/Forms
The standard is very similar to what we have for the WYSIWYG editor:
- vertical alignment
- display of labels (we have uppercase text for Colibri style consistency)
- display of hints/error messages
- primary/secondary buttons
I made a proposal to integrate this standards inside the platform:
http://incubator.myxwiki.org/xwiki/bin/view/Standards/FormsProposal
- administration
- object editor
- user profile
- Create Space/Page
- Copy/Rename Page
Any feedback is welcomed,
Caty
5081
days inactive
5101
days old
12 comments
8 participants
participants (8)
-
Ciprian Amaritei -
Ecaterina Valica -
Guillaume Lerouge -
Marius Dumitru Florea -
Raluca Stavro -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol