Basically, having multiple forms in a row isn't possible so far as I've seen.
LastUpdate
Given the situation with phones and
the unpredictable nature of how most
the browsers render the page, I think
I have to go with multiple buttons per
form. Not super happy with this since
it feels like a WebForms hack for MVC
but it makes the most sense for the
situation. Making a complexish ui for
mobile devices is tough in WebForms,
looks to be harder in MVC.
Something I've been reintroduced to is the idea of having multiple forms per page so that you can have buttons post to different controllers. Problem is that turns out a form is a block element so that it's not possible to get to button next to each other. (Why they are block elements I'd like to know.)
Now here's the main problem, this is a site that was build to be viewable on most phones with a browser. It also has a lot of buttons due to buttons being a lot easier to click with touch phones like iPhones. Floating may not (Not completely ruled out) be an option as floating isn't very predictable on phones. Inline sometimes works sometimes not with browsers as I've seen.
This is sort of a large problem from a design standpoint and I'm hoping there's some kind of MVC method for creating a magical button that would work.
Clarification:
I think the best way to put this is I'm using some buttons as links. In the WebForms version, there were a few of the buttons that basically just redirected. So with that in mind:
Say I have three buttons but all three will need to post to different pages. This would suggest 3 different forms. Unfortunately that would also mean all three buttons would now appear as block elements. (Even though that's it's the form causing this.) Maybe I should be asking if in MVC there is a way to post back to the same controller to redirect from there? Redirect I've done, so that's not a big deal. Posting to a controller and evalutating a button based on it's value I haven't, but that almost seems like trying to recreated WebForms functionality of postback.
Example http://www.eythere.com/images/eythere.jpg
From that image, the top three buttons are merely postbacks to redirets.
UPDATE:
Have attempted tables and floating divs. Tables don't work well with small phones like Razors since they tend to ignore TDs and just make on big vertical column.
Tried floating divs like thus:
<div >
<form >
<input type="submit" style="float:left;"/>
</form>
<form>
<input type="submit" style="float:left;"/>
</form>
<form>
<input type="submit" style="float:left;"/>
</form>
</div>
Problem is it shows the buttons in two rows (That's fine) but the two buttons in the same row aren't aligned vertically. The second one is off by a little bit. Almost to the point that it looks like a Final Four bracket.
May have to go with the multiple buttons to a form thing. This seems to contradict the MVC design but I don't see another way around this.
When you post a form, the name attribute of the button used to post it is sent as a form value. Give each button a name, and then check the Form collection (or an Asp.Net MVC intermediary) for the button's name.
if(!String.IsNullOrEmpty(Request.Form["myButtonName"])) {
//myButtonName has been pressed.
}
EDIT:
Problem is that turns out a form is a block element so that it's not possible to get to button next to each other. (Why they are block elements I'd like to know.)
Forms are block elements because if they were inline elements it would be invalid to nest tags like p and div inside of them (both of which are handy in constructing forms).
If I understand what you are asking, then sorry there is no such function. You would have to find or create your own method that would identify the client and then output the correct HTML code and CSS to accommodate that device. It may be better to find a solution on the user side of the code. You could maybe use display:inline; to forge the button to act like an inline element no matter what. It should work in all major browsers (http://www.quirksmode.org/css/display.html), and this this probably includes the iPhone browser because it is safari based.
It would probably help if you could explain a bit more about how you want the stuff to interact. That said, no law says a form can only have one submit button, and, when submitted it is possible to figure out which button is clicked--the name/value (text) of the button appear in the posted data. Exactly how to handle that really goes to what needs to happen and how you want to architect it, but you can definitely give a form multiple buttons.
--UPDATE--
Thanks for the clairifications. I think your best bet would be to use normal links and style them a bit:
a.button { display: block; width: 100px; float: left; }
They should be nice big clickable things in iTouches and in other more modern mobiles and degrade nicely in older mobile stuff as there really ain't nothing that can do HTML that doesn't support links.
this might solve your problem
another solution: if you can use javascript, make a DIV and a onclick action on it
like what Jeff did here on SO with the [Votes] | [Answers] | [Views] "button" on the home page on the left side of every question
Use css to style anchor links like buttons. That way you get rid of the useless forms and maintain affordability and clickability.
I haven't tried this so I can't say if it will work or not, but could you not just set the forms on the page to "display:inline"?
If you are not collecting data from the user, than they just look like simple links.
HTML buttons don't have to be inside forms. You can have a button with a javascript onclick handler that does whatever you want, like setting a form's action and submit it, or load a new document.
<input type="button" value="Home"
onclick="location.href='/index.php'" />
<input type="button" value="Rooms"
onclick="var f=document.getElementById('myform');f.submit()" />
<input type="button" value="Create"
onclick="var f=document.getElementById('myform');f.action='/create.php';f.submit()" />
Those buttons can then be styled in any way.
If your form isn't collecting data, then all your buttons can behave like the "Home" button in my example.
Related
Our Design System wants primary buttons on the right, secondary buttons on it's left. This is especially great if the primary button will continue to the next step of the form.
At the same time our accessibility guidelines want focus to jump to the primary button before the secondary buttons, which seems legit as well.
Does anybody have some test results whether this is terribly irritating to keyboard users?
We could use flex-direction: row-reverse to implement it.
.button-group {
display: flex;
flex-direction: row-reverse;
}
.button-primary {
font-weight: bold;
}
<form>
<label>
Last input of form
<input type="text" />
</label>
<p class="button-group">
<input type="submit" value="Continue" class="button-primary">
<input type="button" value="Save" class="button-secondary">
</p>
</form>
There is nothing wrong with focusing the primary action before the secondary action here.
People often misinterpret WCAG 1.3.2 to mean that every item on a page must exactly follow the DOM order.
It is a little more nuanced than that. What 1.3.2 covers is that you must not change the meaning of the page. So if you had a block of text and used absolute positioning to reorder that text visually this would break the ordering for someone using a screen reader.
If you look at Understanding 1.3.2 guidance you will see an example that may surprise you and is semi-related to what you are doing:
Examples of Success Criterion 1.3.2 - Example 2: CSS is used to position a navigation bar, the main story on a page, and a side story. The visual presentation of the sections does not match the programmatically determined order, but the meaning of the page does not depend on the order of the sections.
As you have correctly identified the buttons so that pressing enter does submit the form (type="submit" and type="button" respectively) the expected behaviour is there for keyboard users anyway.
The only thing I would point out is that a lot of people who use a screen reader still use internet explorer, so perhaps have a fallback style sheet that uses float: right here that is conditionally loaded for IE as support for flex is not good in IE.
This actually the correct implementation. I did something like this in one of my project on Modal window and was much liked by client as well as user.
I am looking for a way to format a section of my page so users can easily copy a small block of text while on a mobile device.
Are there any classes in Bootstrap, some HTML, or a way to format my CSS to make this easier. I know browsers except IE don't like javascript copying text to the clipboard.
Since your question is specific to HTML & CSS for mobile, here are some thoughts.
I find that having large hit areas available on the elements you want the user to interact can help to start with. E.g. paddings on <p>s for example. So when a user starts tap-holding to initiate text selection, it'll more likely fall on the hit area of the paragraph. (A nifty trick is replacing margins with paddings!)
Try to make sure your content that is selectable follow a natural content flow box model. No weird floats or absolutely positioned content or otherwise content that might confuse the selection widget. Make it as document-like as possible!
Read up on the ways that you can control selection, e.g. user-select CSS property - https://developer.mozilla.org/en-US/docs/Web/CSS/user-select
You might want to disable text selection on elements that don't make sense, to help make text selection cleaner on the parts that matter.
Large font sizes are obvious, but maybe not so obvious is very large line-heights is fantastic for making text-selection a little less awkward! It can improve readability greatly on the side as well, my favourite for body text is line-height: 1.6;.
If you use viewport meta tag, make sure they can zoom in to fill the text/paragraph edge-to-edge comfortably when they want to. This can help a lot to get up close, to do the text selection and get tactile with your content.
However, if you do want to try JS, then I would recommend clipboard.js: https://clipboardjs.com/
Think also about what your users want to copy ahead of time, you might be able to do some analytics and allow users to highlight common text. This is done on Medium by the way to lead as a good example.
You could make it so that when they click on the element, all the text is selected automatically, so all they had to do, assuming they're using a modern mobile device, is long-tap and press copy to clipboard.
document.getElementById("TextParent").onclick(function(){
fnSelect("TextParent");
});
So your html would look something like the following:
<div id="TextParent">
Click anywhere in this div to select this text!
</div>
Adding to this, Nexii Malthus has a good point in regards to the hit areas on mobile phones, so maybe try to add some extra padding to the div.
You should definitely try https://clipboardjs.com/.
<!-- Target -->
<div id="bar">Mussum ipsum cacilds...</div>
<!-- Trigger -->
<button class="btn" data-clipboard-action="copy" data-clipboard-target="#bar">
Copy to clipboard
</button>
and activate it using following javascript new Clipboard('.btn')
Look created sample https://jsfiddle.net/gevorgha/fbeof421/
Note
There are some compatibility issues with iOS devices that do not copy target on trigger action, but it selects target and allows user to copy it manually.
Let's say I have the following section on a form
Form Section:
Data:_____________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
and I want to be able to insert {{ data }} into the section while keeping every line (even if it's unused). I'm doing this for work to replicate an old form. This form has to be identical and that's why I can't simply do something like:
<u>{{ data }}<u>
Thanks in advance for any and all help!
There seem to be a couple of options here;
Hacky: Use multiple text inputs. Style them to have a solid bottom border (as the underline) and use a bit of javascript to handle moving between them on word wrap/arrow key movement. Downside: you'll miss something like handling text readers properly, obscure keyboard shortcuts, etc... Also, while pasting is fairly easy, copying would be a pain.
Use a textarea with a background-image with the lines. This relies on you locking down the font size/line spacing to look right
Html5: look into using contenteditable attribute. you should be able to replicate the appearance fairly easily using css and divs/spans. Then make the right one editable
This post might be helpful. How to underline blank space in CSS?
In their example, you would put your template code in the first span.
At work we had a situation in which a client required a web front for one of our products. None of use are web developers but since I was finishing up on my previous project I volunteered to give it a base.
I have spent the last week or so reading up on best practices and asp.net web forms. Based on requirements we settled on HTML 4 / ASP.NET / CSS 2.1. The customer is going to use the latest browsers so I got to concentrate on nice clean layout.
I have been working on samples using the 960.gs system and I am finding it pretty handy to lay out content without too much trouble, but, I have a major issue.
With all of the tutorials I have seen, they tend to stop or become quite vague as soon the inner most content layout is reached.
Is there any best practices here? or is there any tutorials regarding laying out the inner most content.
What I am talking about for instance is laying out the following:
<div id="question_1" >
<asp:Label runat="server">Question 1</asp:Label>
<asp:Label runat="server" >What is the name of the guy from the other thing?</asp:Label>
<asp:RadioButton runat="server" Text="Yes"></asp:RadioButton>
<asp:RadioButton runat="server" Text="No"></asp:RadioButton>
<asp:DropDownList runat="server"></asp:DropDownList>
</div>
The above html represents a fictional question object. This would be on a list of questions page, much like a survey. Currently, because I can't find the info I am pretty much using css to absolutely position the elements since, because I am using a grid system, I know the width of the box that this div is contained in.
EDIT: By absolutely positioned I mean within the containing element not the page as a whole... Just to clear that up.
From a form layout perspective there are two things to consider: usability and accessibility. Usability defines things like labels going on the left, fields on the right. The exception in this case being with radio buttons and check boxes when the label goes on the right.
Accessibility, defines that each field should have a label tag; fields should be logically grouped etc.
The RNIB have a collection of articles on web design which touch on accessibility and usability. Personally I think they are a great place to start.
EDIT:
Meat & veg answer: The ideal coders (should) try and achieve to style the form but maintain the flow, i.e. ensure that labels for text fields are styled to appear to the left but appear before the field in the HTML.
So, yes it is good practice to:
Wrap each label/field pair in a div, allowing you to clear/position this separate to other pairings.
Make the label display:block with a fixed width and float:left
Don't forget to add required * - I usually use a span within the label so I can control the style of the required * separately.
Use <fieldset> tags to group and style sets of label/field pairings
Unless you are trying to create a highly stylized form, avoid absolutely positioning anything you don't have to. I find that as soon as I absolutely position one thing, I have to absolutely position others for consistency so you should always first try and find a solution which allows elements to control the position of subsequent elements
I know developers who still use tables to arrange their forms. Is this bad? Yes, but it works and for a temporary solution or small, rarely used form this might be an appropriate trade-off.
Scott on Writing has a nice article on basic form styling. This guys is awesome and knows what he is talking about.
And also there are jQuery tools for creating nicer more responsive controls:
jQuery UI
Multi select
I think the ideal is to use CSS purely for the layout and presentation, and HTML for the content. But let's say, the company wants to change a "Related articles" box from the bottom of the page to the top of the page. In such case, won't using CSS alone be not an ideal solution, but is better to alter the HTML as well? So as things are right now, HTML still takes a role in the page layout and presentation? Thanks.
Things still appear in the same order as they are in the html - it's not as restrictive as that as we can use absolute and relative positions, but those are undesirable - it's better to use to dom flow to handle placement, and that means yes, you should move the node in the html.
As Jason said, CSS is for styling the content, the content itself and its order is defined by the data (html), as order is necessary for the context of information, so it lies firmly in the 'data' part of what we do rather than the 'display'
EDIT:
I should say this: If you want your data to be totally independent of the display, you should consider defining your pages as xml only and using xsl to define the layout. xsl combines with css to completely abstract the display away from the data.
It does on two levels:
Firstly, the order of elements is still important. CSS floats are used a lot for layout but they also require elements to be in a certain order to get things in the right place. For example, lets say you have two buttons:
<input type="button" value="Click Me">
<input type="button" value="No, Click Me!">
These are next to each other. Lets say someone asks you to move the second button to the far right. This is how you do it:
<input type="button" value="No, Click Me!" style="float: right">
<input type="button" value="Click Me">
If you don't do this, the second (floated) button will appear below the other.
The second way HTML is still important is that there are still things that you need HTML tables for that can't be done in pure CSS at all, in a browser-compatible way (meaning IE6 support generally) or easily. This isn't something the pure CSS zealots like to hear but, like it or not, in the real world it's still true.
This is especially true with HTML emails. If you thought browser support for CSS was bad, mail program support is so much worse. Generally speaking you avoid CSS altogether with HTML emails and just pretend like its still 1999.
HTML still defines the hierarchy for elements.
HTML divides your page in logical sections. CSS then applies a certain look/feel/style to those sections.
If you want to change your page layout to include a section inside another one, you have no choice but to modify your HTML because HTML has a role on page layout.
You can actually move blocks around using nothing but CSS. The compromise always boils down to how good your CSS skills are and how much compatibility with older browsers you're after or care about. There are limits to what CSS can do, so yes, HTML definitely still has a role to play.
it is possible to change the "source order" of divs or use css to change positions. But if its more practical to just change the html, then there's no other way round it. At the end of the day, if its more important content then the source should reflect it for semantic reasons.