I found a CSS treatment I LOVE for forms. However, the place I saw it was ONLY using it for a login box - so they needed two textboxes, both required. I’m trying to figure out what changes I need to make to get it to work with select boxes and also to troubleshoot some textboxes that don’t work correctly.
The dev site we’re using is here:
Navigate to the Profile tab. I’ve commented out most of it but left some that illustrates both issues I’m having. The first two fields - Primary Insurance Company and ID - both work correctly so you can see what I’m trying to accomplish. The next two - Group or FECA Number and Effective date are stuck in the hover state. Those two are just text boxes like the first two and I haven’t been able to figure out why those aren’t working properly. Insurance Company’s Payer ID is the same, i.e., stuck in hover.
The remaining two - Your Relationship to the Insured and Authorize Payment of Benefits to Provider - are both select boxes. The hover state works fine on those - but once you enter something, the label no longer keeps the hover styles - but goes back to the static state - which means that the label and the value you just entered are on top of one another. SOMETIMES on select boxes, the label disappears entirely. I can show you an example of that if needed. I know it’s happening on the Time Zone select box - which has a lot of options - so number of options could have something to do with it.
One other thing about this code - it doesn’t work if you remove the “required” attribute. We only need to mark a handful of items as required, but with the existing CSS - since it was originally intended to be only for a username password form - won’t work without all fields marked as required.
One other thing about this code - it doesn’t work if you remove the “required” attribute.
That’s is the crux of the problem as the Css is using the :valid pseudo class to style the inputs and labels and that only works on inputs that have the required attribute. Optional inputs are basically valid to start with. I’d like to see where you got that code from as they are probably doing something more than you have added to your code. Selects can use the valid class but also need the required attribute.
You may need to use a helper script if you want to continue with this format.
I have an old demo that uses :placeholder-shown for styling optional inputs in a similar manner and it may be possible to do what you want.
Here’s the demo:
Bear in mimd this is a bit experimental so I would test with care.
You may be better off writing a small helper script if you run into usability problems with the above.
Thanks, Paul. I wish I remember where I got the code. It was some email that came around showcasing cool forms that only used CSS. This one literally was only meant to be for a login - username/password. I was stunned by it, though. Totally black background and the labels were some kind of magenta. Very dramatic. It was several years ago - I had just saved the code. Sometimes I put the URL where I found something in comments but evidently, I didn’t do that with this one.
Your demo is cool.
I expect you’ve already looked and I don’t presume to tell you anything at all . But the ctrl-u code mentions pqselect.dev and Googling that shows https://paramquery.com/api/select - is that any help?
Thanks, wake, but I don’t understand the implications. I know a little bit about a lot of stuff but master of very little. I have developers working for me and although I do much of the HTML/CSS myself, I turn the rest over to them. However, I’m sure Paul will know exactly what you mean and can chime in. That’s how I learn - by listening to everyone else bat stuff around.
I was able to fix some of the errors I had yesterday by making sure everything (even select boxes) DID have the required attribute - and also labels. Some of the things that are not working are a couple of select boxes that look like they just need a default value - which - the way this code is written - I don’t know how to do, but I’m sure my developers will. There’s also an issue with “Effective Date” which needs 3 textboxes - MM/DD/YYYY. Again, I suspect we’ll be able to find a workaround for that.
Paul, your :placeholder-shown demo might work - but I have so much on my plate at the moment, I’m not sure I have the bandwidth to figure out how to adapt it and adequately test it.
You can use the input type=“date” these days which makes it a lot easier.
Whatever you do you still have to check serverside to check the integrity of the data and that it meets your requirements. Some people will have js disabled anyway so all your validation will fail on the client side. Use the built in browser validation where possible and then augment with js if needed.
Form validation and form display are really 2 separate things.
If you want optional inputs to behave like the required inputs then you’d need to use the placeholder method I have shown or use js to swap classes as appropriate and use for styling etc. I’ve checked my placeholder demo on a Mac in Firefox, Chrome, Safari and ios and it works in all of those. It should also work in Edge and I don’t support IE11 anymore. (You could probably build in support fo IE11 by using @supports to hide all the rules from ie11 but haven’t tested.)
You should also be building in to your form suitable error messages that display when a field is invalid or when submission fails. Designing a fully functioning form is a complicated process.
Thanks, Paul. I did NOT know about type=“date”! Looks like a very handy tool. Part of what makes this particular project problematic, is that we’re creating another access point to an existing form. It’s a medical app - the doc has one form they’ve been using (which was built probably 10+ years ago - only look and feel updates). Now we’re building the same form for patients to input their own data. Both doc and patient will be able to input data - the doc has “refusal rights” if the patient enters junk or tries to erase their chart, etc. But it all populates one basic chart. So all of the names on input forms have to match up. We already have all the error messages there for the original form - so those can just be copied over. And . . . of course . . . we’re also trying to launch this reasonably quickly. I sort of think I’d rather wait and update ALL of the date inputs we have throughout the app, rather than doing them one at a time. There is SO much cool stuff we can use now.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.