Forms API Incompatibilities

[ebollens]

In the initial draft of the Forms API Specification, the class for form styling was form.form-full. However, when we moved to lean CSS names for MWF 1.3, we elected to drop the -full qualifier. This would have meant that ideally the Forms API would have been invoked using form.form. Unfortunately, the implementation that made it into MWF 1.3 was for all form elements rather than form.form. While the class name might seem redundant in some cases, the problem is that without it, all forms get styled, regardless of context.

The best example of how this breaks things:

<form>
    <div class="menu">
        <ul>
            <li><a href="#">Link</a></li>
            <li><a href="#">Link</a></li>
        </ul>
    </div>
<form>

It ends up pushing some strange padding into the menu definition itself because definitions from the Forms API leak into the DOM.

There are a few solutions that might jump to mind:

1. Require .form to use the Forms API.
2. Add a .unstyled class to the Forms API and make all definitions in the scope form:not(.unstyled) or equivalent.
3. Modify .menu, .content, etc. so that they beat out the definitions of the Forms API.

I would say that (1) is a non-starter because it will break apps already on MWF 1.3 using Forms API. This leaves us with two other options. Because Forms API doesn't screw with padding for basic phones, we might assume that :not is available, but I'm not convinced that this is the case for Windows Mobile and Blackberry devices classified as standard. This would mean that implementing (2) requires instead reversing the affects of the Forms API. Not sure I like this, as it requires content providers to make changes anyways. That leaves (3), which is tricky but might be achievable with techniques like negative margins.

Why does this matter? The predominate case I've seen this in (four production apps at UCLA) is .NET. It seems that it is a common practice to wrap the full page contents in a form. Experimentation will show whether or not this is reasonable either.

Some fix should be sought for the next MWF release to ensure that we aren't creating a barrier to upgrades for service providers that haven't moved to MWF 1.3 yet.

@ilin @loganfranken @Trott @edsakabu @rrocchio

[ebollens]

Margin trick does not work because widths cannot be determined reasonably.

Consider this definition:

form #header {
    margin: -10px -10px 0 -10px;
    border-radius: 0;
    -webkit-border-radius: 0;
    -moz-border-radius: 0;
}

While it puts the header back in the upper right hand corner, it can't make it the right size. The only way to figure this out would be if CSS supported something like width: 100% + 20px but alas it does not.

[ebollens]

The strategy of using :not(.unstyled) does work, but only on fully capable devices. Again, not a solution.

I could use some ideas here. I'm not sure how one can resolve this.

Of course the other argument is to say "F IT!". It's the first time we've had to ask a content provider to do something to support an upgrade of MWF, and arguably you shouldn't be doing this anyways. HTML is supposed to be semantic, and placing a form around the entire page would argue that the entire page, including the header and footer, are all part of the form, which isn't true by the way we've got those defined. Same thing goes with a menu. Why would you put a menu inside a form? A menu is a list of link items, which by definition are not part of the form, because they are not form controls. Unless someone else has an idea, we might be stuck with this route.

[loganfranken]

To provide some context: it's the ASP.NET Web Forms model that (sometimes) requires the containing form tag. Basically, (I apologize if I'm explaining something everyone already knows) the ASP.NET Web Forms model works by stuffing a bunch of hidden inputs into your page and using a little JavaScript indirection to make you feel like you're developing a stateful WinForm (you can clearly tell that I just adore it).

It's a misconception that you need to wrap the entire page in a form, though; as far as I understand it, it's only the data-centric controls that require it (see: http://www.devprise.com/2007/06/07/aspnet-what-server-side-controls-require-a-server-form/). On the UCSB FinAid website, for example, the extra bloat gives me the heebie-jeebies, so I only wrap the necessary controls with form: http://www.finaid.ucsb.edu/m/Default.aspx vs http://www.finaid.ucsb.edu/m/ContactUs.aspx

ASP.NET MVC websites would not suffer from this same problem.

If we can't do anything about it, maybe we just at least provide some information describing the problem for ASP.NET Web Forms developers?

Also, 1 seems like the most viable option; when would we be able to apply that change? 1.4?

[ebollens]

@loganfranken all minor release versions (1.x) are supposed to be backwards compatible for content providers so unfortunately option 1 is a non-starter even if we released an MWF 1.4. However, the community decided not to push forward with MWF 1.4, but instead focus on a responsive toolkit, so even if this were an option, it would be a no-go.

As such, I agree we need to provide some documentation. Could you take a pass at describing how one would go about refining the scope of the Web Forms model, as I'm completely unfamiliar with .NET.

[loganfranken]

Yup, I'll take a shot at it.

[ebollens]

@loganfranken how goes writing this up?

[loganfranken]

@ebollens Blargh, sorry for the wait; I'm a little swamped at the moment. I'll be working on this a little later his week.

[loganfranken]

@ebollens Actually, while I'm thinking about it; you mention a couple pages that suffer from this issue? Would you mind sending me a few examples so that I can base the write-up on real-world issues?

[ebollens]

@loganfranken they've already resolved themselves. But if you want to see it quickly, just echo a form tag around any of the content or menu elements on one of your local pages and you'll see the bug immediately.

[loganfranken]

@ebollens Oh, sorry, no, I was unclear: I totally understand the problem at hand, but the main issue is that I probably can't offer an actual fix for ASP.NET Web Forms developers, I would instead be offering alternative solutions for how to make Web Forms and MWF work well with each other. I was just wondering if there were real-world examples of where this problem occurred so I could base my advice around those (rather than offering ivory tower solutions).

Not really a big deal, though; I think we also have a few examples here at UCSB. Anyway, I'll get to work on this as soon as I can!

[loganfranken]

Sorry for the crazy long wait (3 months!): I need to tidy it up a bit, but I've put together a repo (https://github.com/loganfranken/MWF-ASP.NET-Web-Forms) that contains (1) general guidelines for structuring ASP.NET Web Forms to avoid these issues and (2) a stylesheet that can be added to override thee issues.

Hoping to finish it up a little later today.

[ebollens]

@loganfranken this looks great! My question is how we work this into MWF. We might want to offer the following...

(1) Leverage themes support through config:

• Add the style directory to root/assets/css as say dotNET
• Document that you can enable this by adding custom[]="dotNET" to config/css.ini

This is good for service providers that want to enable this globally.

(2) Provide a flag for css.php:

• Content providers use compat-dotNET as a flag to inform css.php that they want this
• Modify css.php to not just load default but also dotNET if the flag is set on css.php

This is good for content providers when the service provider doesn't want to just always add bulk. We could direct them to your .NET example to show them how to implement if they're confused, although at this point we're escaping the whole problem of leaking definitions and then all it comes down to is them actually informing the system of what they're doing through class semantics.

Thoughts?

/CC @edsakabu @Trott

[loganfranken]

@ebollens Thanks!

I wrapped up the styling and the documentation. I'm a fan of Option #1 (the updated README includes instructions in that vein), but I'd be interested in what others think about it.

[ebollens]

My thought was we could provide both options and let service providers decide.

[rrocchio]

Closing this issue as this system has long since been deprecated.