Why does the WHATWG disallow nested forms in HTML 4 and HTML5?
EDIT:
Problem is originally described at How do you overcome the HTML form nesting limitation?
In short author says:
You are making a blog app and you have a form with some fields for creating a new post and a toolbar with "actions" like "Save", "Delete", "Cancel"...
The only problem is that pressing "Delete", will submit ALL the form fields on the server even though the only thing needed for this action is a Hidden input with the post-id.
So, it is a question about an elegant solution (without JavaScript) for several buttons in a form to submit different sets of input fields (like several forms could allow) and to line up UI into single entity ("form") from user perspective.
Comment from that discussion: it's almost impossible to completely separate the elements' screen position from their position in the document.
EDIT: I found interesting note https://web.archive.org/web/20170420110433/http://anderwald.info/internet/nesting-form-tags-in-xhtml/ - that (X)HTML disallows nesting forms like "form > form", but allows "form > fieldset > form", W3 validator says it is valid, but browsers have bugs with such nesting.
As far as HTML5 (the draft spec) goes, the situation is not nearly as clear cut as David Dorward suggests. What is true, is that there's no way that nested forms can be specified in the text/html serialization in a backward-compatible way without adding a new way of delimiting forms in markup.
On the other hand, in the application/xhtml+xml serialization, it's not only possible to markup nested forms, but HTML5 goes to some lengths ( http://dev.w3.org/html5/spec/forms.html#form-owner ) to specify what should happen in this case. Further, a quick test around the latest versions of FireFox, Opera, Chrome, and Safari, plus IE9 platform preview shows that they all do what HTML5 specifies.
So, it could have been valid in the HTML5 content model, but it isn't. What determines what is valid and what isn't rests largely on use-cases. So far, no one has provided a sufficiently compelling use case to WHATWG or the W3C HTML WG for making nested forms a part of valid HTML5.
WHATWG doesn't disallow nested forms in HTML 4 — they have nothing to do with the language, and they don't have as much to do with HTML 5 as you seem to think.
Nested forms are not allowed because they wouldn't make sense, and if you specified something vaguely sane, it wouldn't be backwards compatible with current browsers.
Related
HTML select widget is very constrained in how it can be styled. To work around this, there are many libraries attempting to reimplementing it using JavaScript, but most lack one or another feature which is available in the native version. Here are a few features which are hard to find in a single implementation:
arrow keys can be used to go through the options of a focused select element without opening the popup
possible to jump to an option by typing letters it starts with
the popup opens at the top if there's not enough space at the bottom or if opening it at the bottom would require making the options popup scrollable.
Is there a specification somewhere listing all the features the native select widget supports?
I'm aware the implementations might be platform-dependent, but it would be useful to have docs for any of them.
The best I could find was information on a similar component - combobox:
https://wiki.openjdk.java.net/display/OpenJFX/ComboBox+User+Experience+Documentation
https://www.w3.org/TR/wai-aria-practices-1.1/#combobox
https://developer.gnome.org/gtk3/stable/GtkComboBoxText.html
In the HTML terminology, it's called the select element.
You can find its specification in the HTML 5.2
W3C Recommendation, section 4.10.7
You can also look at the same section in working draft of the upcoming HTML 5.3.
I have a form that normally works with respect to dirtyforms. However, there is one circumstance where a jquery-ui datapicker calendar will pop up the "are your sure" dialog when a date is clicked.
I emphasize that this normally works correctly. The situation is related to the initial conditions of the form data source. Things work when the object being referenced is existing, but not if it is new. So I am sure somewhere there is a difference in the initial conditions of the form. But in theory the form should be identical.
How can I find what is causing the popup so I can fix my issue?
Well, I did find what was causing my problem by comparing the HTML of the working and non-working situations. (Not an easy task since there were many non-relevant differences.)
Seems that the original coder did a strange thing. Left out some Javascript function declarations when the page was "new" but of course did not eliminate the calls on those functions.
So I guess that the javascript errors were the root cause. At least when I include those function declarations everything works correctly.
By default, most anchor links on the page will trigger the dialog. We don't have a hard-coded selector of all potential 3rd party widgets, you must manually take inventory of whether these widgets use hyperlinks and ignore them if they are causing errant behavior.
See ignoring things for more information.
I was unable to reproduce this behavior using Dirty Forms 2.0.0, jQuery UI 1.11.3, and jQuery 1.11.3. However, in previous versions of Dirty Forms, you can probably use the following code to ignore the hyperlink clicks from the DatePicker.
$('.ui-datepicker a').addClass($.DirtyForms.ignoreClass);
I have something like the StackOverflow's "Ask Question" page, where a text-box is used to put source markup code and, below, another text-box (non-editable) is used to render a preview of the post/question being typed.
Consider that my application not only lets me use a simple tiny markup language for my posts' content; it also provides me with the possibility to type math in it using MathJax. But the syntax is simple Latex syntax (however this is not the problem, so do not let this thing bother you too much).
The problem
The problem is the following. The page is a little different from the StackOverflow's one because it uses ASP.NET with AJAX in order to call a server-side procedure that performs the markup language translation in HTML (this is my choice, I have the code server-side, there is no implementation in javascript of the markup translation code).
When the asynchronous script runs (every 10 secs), the non-editable text-box is re-filled with the translated markup. The Latex code as well is put there (no translation performed on it) and MathJax script is called everytime the AJAX procedure returns (so the latex code will be rendered after the markup language, this latex rendering happens client-side).
The problem is that, sometimes, rendered math is strange especially considering equation numberings. Numbers do increase every new AJAX call. I guess there must be a way to reset, completely, the status of the MathJax object instantiated in the page or whatever... Is there a way to reset MathJax?
I assume that AJAX here is the problem... Thankyou for your help, hope I was clear.
If you have loaded a configuration file that includes the AMSmath extension, you can use
MathJax.InputJax.TeX.resetEquationNumbers()
to reset the equation numbering and the labels used for \ref and \eqref. If you want to start the numbering at a particular equation number, use
MathJax.InputJax.TeX.resetEquationNumbers(n)
where n is the starting number minus 1 (the default is 0).
I'm building an MVC framework, and I'm looking for native solutions / frameworks / tag libraries to draw from or to replace my framework entirely.
I'm interested in the following features specifically:
server-side DOM manipulation
server-side events (page reload, form submit, node insertion, etc.)
traversing the DOM tree using css selectors
validation of html nodes nesting
validation of html nodes allowed attributes
support for tag libraries / user controls
Pretty much what you get with JavaScript, but on the server-side and with some little extras.
Any solution will do (even if partial), any language will do, any pointers are appreaciated (even from client-side languages, as long as it's possible to check the source code). Dealing with malformed html is not a prerequisite. Outputting valid markup is a big plus.
Please offer practical solutions by pointing the language/framework that is being discussed and, if possible, what features it provides.
have you checked out aptana jaxer?
If you load your page into a DOM-parser you would be able to modify it from there. Then outputting it to the output buffer seems trivial.
But you would need to store the entire document in memory, which will inflict on the performance.
So, jQuery has a sort of selectors API implemented, I guess I can take a look at their source code. Also, PHP has support for XPath, this could help too.
Found a php html dom parser that also implements some html selectors here: http://simplehtmldom.sourceforge.net
Fizzler uses HTMLAgility pack and adds a server side queryselectorall to provide css selection: http://code.google.com/p/fizzler/
Maybe you are looking for ItsNat
I am developing an issue tracking application in Django, mostly for a learning exercise but also for my own projects - and I am looking into using some AJAX for "enhanced" usability. For example, allowing users to "star" particular issues, which would add them to their watch list. This is implemented in a lot of sites, and is often AJAX - as the URL that the user is viewing doesn't need to change when they click the star.
Now, I am wondering what kind of response to return from my star_unstar view - that detects whether the request is being made via AJAX or not.
At present, if the request is an AJAX request, it returns just the section of HTML that is needed for the star, so I can replace the HTML in the star's parent DIV, so as the star appears "on" or "off", depending on the user's action.
However, I would much rather return some kind of JSON object, as it just seems more "proper", I think. The problem with this method is that the javascript would have to modify the star image's src attribute, the href on it, and the link title also, which seems a lot of work for such a simple feature. I am also looking into in-line commenting in the future, but I want to get a feel for how things "should" be done before I start coding lots of JS.
What is the general consensus when implementing features such as this, not just with Django, but all frameworks that operate in a similar way?
When I work with Ajax my main concern is usually to limit the amount of data I have to send. Ajax applications of this type should be very responsive (invisible if possible).
In the case of toggling a star, I would create the actual on/off states as CSS classes, StarOn and StarOff. The client will download both the off and on star when they first visit the page, which is acceptable considering that the star is a small image. When you want to change the star appearance in the future, you'll only be editing CSS, and won't have to touch the javascript at all.
As for the Ajax, I'd send back and forth one thing -- a JSON variable true/false that says whether or not the request was successful. As soon as the user clicks on the star, I'd change it to the StarOn state and send out the request. 99% of the time Ajax will return true and the user will not even realize that there was some sort of delay in the web request. In the rare case where you get a false back, you'll have to revert the star to StarOff and display an error message to the user.
I don't think your question relates particularly to Django or Python, as you point out at the end.
There's a lot of personal preference in whether you return a blob of HTML to write into the DOM or some serialized data as JSON. There are some practical factors you might want to take into account though.
Advantages of HTML:
- Easy and fast to write straight into the page.
Advantages of JSON:
- Not coupled to the front-end of your application. If you need that functionality anywhere else in the application, it is there ready to go.
My call on it. It's only a relatively trivial amount of HTML to update, and I'd probably go for returning JSON in this case and giving myself the extra flexibility that might be useful down the road.