[whatwg] Submitting form question
Hi, When submitting a form, whose method is GET and action is identical to the current location, except for the fragment, should that trigger reloading the page, or simply navigating to the fragment? The background for my question is in the analysis done in https://bugs.webkit.org/show_bug.cgi?id=20342#c35 thanks, Yael
[whatwg] sic element, was: Re: Exposing spelling/grammar suggestions in contentEditable
Am 30.12.2010 um 02:47 schrieb Ian Hickson: On Tue, 30 Nov 2010, Martin Janecke wrote: I support this idea and I'd certainly use it. For example, I'm currently copying an old rhyme book to hypertext and would love to mark historically correct (but now incorrect) spelling, spelling intentionally done wrong for better rhyming (yes, people did this in the past) and unintentional errors from the book semantically. I think it is important to note where those errors are done intentional (by me, the publisher of the web page) in contrast to errors accidentally added by me that differ from the copied book. mark is the element for this purpose. I don't think mark is appropriate for what I meant. I as the publisher usually don't mean[1] to point a readers attention at spelling errors by someone I quote, I just want to be able to add semantic markup that identifies a part of text as deliberately published just the way it is published. Here's an example of a webpage quoting the US constitution http://en.wikisource.org/wiki/Constitution_of_the_United_States_of_America#Section_2: The House of Representatives shall chuse their Speaker and other Officers I'd like to be able to code this as The House of Representatives shall sicchuse/sic their Speaker and other Officers to record that I intentionally wrote chuse, not choose, as chuse is exactly what the constitution says. But I wouldn't highlight chuse to the reader. The fact that there's archaic spelling in the constitution is not what the page is about and irrelevant[1] to the common reader e.g. in context of learning about the US legislative branch, and hence not worth being marked with mark. Using mark on the original author's spelling errors, idiosyncrasies etc. would often even distract[1] readers from what is to be expressed with a quote. Consider a reader who searches for the term speaker at http://en.wikisource.org/ -- clearly the term speaker is of major importance to him, chuse is not. The returned search result should look like this: Constitution of the United States of America: ... House of Representatives shall sicchuse/sic their markSpeaker/mark and other Officers ... Regards, Martin ___ [1] compare with http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-mark-element: The mark element represents a run of text in one document marked or highlighted for reference purposes, markdue to its relevance/mark in another context. When used in a quotation or other block of text referred to from the prose, it indicates a highlight that was not originally present but which has been added to markbring the reader's attention/mark to a part of the text that might not have been considered important by the original author when the block was originally written, but which is now under previously unexpected scrutiny. When used in the main prose of a document, it indicates a part of the document that has been highlighted markdue to its likely relevance/mark to the user's current activity.
Re: [whatwg] Submitting form question
On Thu, Dec 30, 2010 at 9:06 AM, yael.aha...@nokia.com wrote: When submitting a form, whose method is GET and action is identical to the current location, except for the fragment, should that trigger reloading the page, or simply navigating to the fragment? As I'm reading the spec, you're doing Mutate action in step 19 here: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#form-submission-algorithm Then in the navigation algorithm, step 7 says you just navigate to the new fragment and don't reload the page: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate The background for my question is in the analysis done in https://bugs.webkit.org/show_bug.cgi?id=20342#c35 Your conclusion appears to match mine, if I'm reading you right. HTML5 is confusing sometimes, but it sure is precise.
Re: [whatwg] sic element, was: Re: Exposing spelling/grammar suggestions in contentEditable
On Thu, Dec 30, 2010 at 8:55 PM, Martin Janecke whatwg@kaor.in wrote: I don't think mark is appropriate for what I meant. I as the publisher usually don't mean[1] to point a readers attention at spelling errors by someone I quote, I just want to be able to add semantic markup that identifies a part of text as deliberately published just the way it is published. Indicating where mistakes have been reproduced in transcribed or quoted text seems like a different usage than Charles's application of marking mistakes in editable text for potential correction by the end-user. Bearing in mind: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F 1. What problem(s) does indicating where mistakes have been reproduced solve? 2. What other solutions to this problem might there be? 3. What's the advantage of using markup to do this rather than visible text like deadtree. What's wrong with The House of Representatives shall chuse [span lang=lasic/span] their Speaker and other Officers? 4. It seems like sic would be a very rarely used feature. Why do we need to include it in the small, core HTML vocabulary rather than an RDF vocabulary imported into HTML via annotations like RDFa, microdata, or microformats? -- Benjamin Hawkes-Lewis
Re: [whatwg] Workers: what should happen when exceeding worker limit?
On Thu, 23 Sep 2010, Ivan Kozik wrote: What should happen when instantiating a Worker that cannot be started because of the limit on the number of workers? That's a hardware limitation, and as such is something we tend to leave up to the user agents. In practice, it's often the case that user agents are very constrained in how they can deal with hardware limitations (e.g. if the user agent cannot allocate more memory, then it might not be able to allocate memory to fire an exception, or to keep track of the worker to run it later), and therefore we tend to leave that open. So long as the limitations are big enough that most pages don't run into them, it doesn't really matter -- a user agent with a compatibility issue can almost always just increase the limits if pages would otherwise break! Chrome 6 and Chromium 7.0.532.0 (60255) put the 17th worker in a queue, to be created when some existing worker terminates. This queue seems to be limitless in size (or at least it is large). In Opera 10.70 (9049), instantiating the 17th Worker throws Error: QUOTA_EXCEEDED_ERR. I guess the simplest answer is don't use more than 16 workers. There's really not much point in doing so anyway, since most systems don't have 16 cores today. (This will naturally change in the future, but then so will the limits.) I'd much prefer that it failed immediately, rather than being put in a queue. Unfortunately we can't really require immediate failure, since there'd be no way to test it or to prove that it wasn't implemented -- a user agent could always just say oh, it's just that we take a long time to launch the worker sometimes. (Performance can be another hardware limitation.) I use a SharedWorker as an enhancement, and I don't want to implement a timeout for the Worker spawning (I'd rather have it fail, so that I can immediately do something else). I can avoid spawning more than 16 workers, but I never know if another tab has already created enough workers to exhaust the global worker limit (64 in Chrome, ~118 in Opera). And if I really want to spawn the worker, I can always try spawning it again soon. If you have performance constraints, then you should just use timeouts to test whether the worker started -- that way you'll do the worker-less fallback behaviour regardless of whether the timeout fired because workers are just slow on the user's computer or because there are no more worker slots available. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input element list attribute and filtering suggestions
On Thu, 23 Sep 2010, Mounir Lamouri wrote: The list attribute on input elements let the author specify a list of pre-defined suggestions via the datalist element (each option of the datalist is a suggestion). It looks like the idea is to have all the suggestions showing like a combobox which is more or less confirmed by Hixie. [http://www.w3.org/Bugs/Public/show_bug.cgi?id=9785] However, it sounds like having a static combobox would only fulfill some use cases (ie. when a very small set of suggestions is defined). In most obvious situations, having a list with all the suggestions would be annoying. So, it might be interesting to have the list filtered with the current element's value to be able to use the list attribute for large list and have a boolean attribute to enable or disable the filtering. There is a distinction between the combo-box style UI of a finite list of suggestions, and Google suggest-style UI -- but that difference is not related to filtering, IMHO. It's more related to the volume of possible data. In both cases you would want filtering for an ideal UI, IMHO. One simple use case would be a city transportation website. If you have to type a station name in a field it might be much more user friendly to have a filtered list. Actually, I do not see any use case of the list attribute without filtering. To me, it seems like a replacement of a select with options and an input fields in the case of none of the above. And I do not think this replacement would be better. I am wondering what were the use cases in mind? The use case is more or less what you describe -- just look around your operating system's configuration UI for instance for lots of examples of this kind of thing. The thing that makes this different than Google suggest-style UI is that in the latter case you need a script that continually polls for more appropriate suggestions and updates the list -- for this kind of thing we'd probably want to use a direct API, we wouldn't want to have scripts have to poke at the datalist DOM in real time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] :invalid
On Thu, 23 Sep 2010, Mounir Lamouri wrote:
The current specification of :invalid is pretty simple: it matches all
invalid elements which are candidate for constraint validation.
Today, Gecko betas, Presto and Webkit support :invalid (I didn't check
for IE). Unfortunately, :invalid is far from being perfect and most
UI/UX guys would tell you that the current :invalid behavior is really
bad. For example, having the invalid style applying as soon as you load
the page (ie. for input required) is not a good thing. There are few
UX rules like that that :invalid currently breaks.
So, to improve the user experience while using web forms we would like
to fix that. However, we are wondering if :invalid (and :valid?)
specifications should be updated to take UX considerations or if a new
pseudo-classe should be created. Does anyone has an opinion about that?
On Thu, 23 Sep 2010, Boris Zbarsky wrote:
I was actually thinking about this the other day... We could add a new
pseudo-class for matching form controls that have their default value
(or that don't, depending on how we expect this to be used). then you
could style :invalid:not(:has-default-value) specially, say
Or I suppose we could just add a new pseudo-class that means the above.
On Fri, 24 Sep 2010, Simon Pieters wrote:
That wouldn't get the right UX if the user tabs through a required field
or tries to submit a form without touching a required field.
I was thinking of :invalid:dirty where :dirty matches form controls that
have received and lost focus or its form has been tried to be submitted,
or some such.
It's not entirely clear to me what the intended UI is here. If the goal is
to only style form elements for (in)validity after they've lost focus or
after their form is submitted, it seems a couple of scripts on form
would be the way to go:
form onblur=event.target.classList.add('examined')
onsubmit=for (var i = 0; i elements.length; i += 1)
elements[i].classList.add('examined')
...along with CSS rules like:
.examined:invalid { ... }
.examined:out-of-range { ... }
On Thu, 23 Sep 2010, Boris Zbarsky wrote:
Are there cases when pages would set invalid default values and want
them flagged as such in UI?
On Fri, 24 Sep 2010, Shiv Kumar wrote:
Typically, in large organizations, there are folks who clean up data. So
they will be presented with data that's already entered by someone else
and their job is to clean up the data. In fact I see the new Form API to
be a very good candidate for this use case.
Indeed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Submit controls should be barred from constraint validation in favor of a new pseudo-class
On Thu, 23 Sep 2010, Mounir Lamouri wrote: It sounds like currently the specifications want explicitly to have all submit controls being subject for constraint validation [1] which seems to be a weird idea. Given that only setCustomValidity() can be used on those controls, the only use case I see is to set the submit controls invalid when the form is invalid thus having :invalid style applying to them. If the given use case is correct, I think we should make all submit controls barred from constraint validation and introduce a new pseudo-class allowing to style submit controls when their form is invalid. Form controls are part of constraint validation for completeness only, as far as I can tell. Anything that's visible and submitted is a candidate for constraint validation. This would prevent having invalid elements styled exactly like the submit controls (which would let the user think the submit control is invalid) and it would prevent having :valid applying on buttons for no apparent reason. I don't imagine people would style :valid without specifying the specific element. I mean, you wouldn't want the same style to apply to your radio buttons and your text fields and you select elements either. This pseudo-class would apply on all submit control inside a form which has at least one invalid element subject for constraint validation. If people want to style submit controls based on the states of other elements in the form, then we could certainly create a new pseudo for that. Do people do that enough to justify it? Current Gecko nightlies (and next beta, beta7) have a :-moz-submit-invalid pseudo-class. Submit controls can still be marked invalid but that might change before the final release if there is an agreement that :-moz-submit-invalid is a better way to fulfill the need. As a side note for web authors on this list, :-moz-submit-invalid currently has a default style on Firefox but that is very likely going to change for beta8. Do people use this feature much? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers: what should happen when exceeding worker limit?
On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson i...@hixie.ch wrote: I guess the simplest answer is don't use more than 16 workers. There's really not much point in doing so anyway, since most systems don't have 16 cores today. (This will naturally change in the future, but then so will the limits.) This logic is only valid if threads are exclusively used for pushing CPU-bound work to other cores. They're not; it's perfectly normal to create more threads than CPU cores, both for disk I/O-bounds threads and network-bound threads. Unfortunately we can't really require immediate failure, since there'd be no way to test it or to prove that it wasn't implemented -- a user agent could always just say oh, it's just that we take a long time to launch the worker sometimes. (Performance can be another hardware limitation.) Preferably, if a Worker is successfully created, the worker thread starting must not block on user code taking certain actions, like closing other threads. That doesn't mean it needs to start immediately, but if I start a thread and then do nothing, it's very bad for the thread to sit in limbo forever because the browser expects me to take some action, without anything to tell me so. Timeouts are an ugly, brittle workaround. They'd have to be implemented for every created thread--even if you aren't creating many threads, another component on the page may be. Timeouts would need to be high enough to not cause false positives even during swapping, which means a delay long enough to be visible to the user. I'd also expect unpredictable behavior on mobile browsers; if the whole browser is suspended after creating a thread, timeouts may expire even though the thread was starting normally. We need sensible, predictable error detection, not silent queuing. I can't think of any case where workers being queued is preferable to failing outright. If queuing is really necessary, please at least give us a way to query whether a worker is queued. That's far from ideal--it would be hard to test user code properly--but at least we could wrap worker creation to throw an exception if our worker threads are being queued. -- Glenn Maynard
Re: [whatwg] HTML5 - 7.4.2 Focus management
On Thu, 23 Sep 2010, Guilherme Johansson Tramontina wrote: I saw that elements with the draggable attribute become focusable. But what about contenteditable? Yes. (I've clarified the spec to make this more obvious.) My main questions/suggestions are: - Should the contenteditable element be focusable? Yes (modulo platform conventions). - And its children elements? Technically, it's the editing host that's focusable. - How about events (like onChange) for the editable element and/or for its children? How do you mean? Here is a simple HTML example: ol contenteditable='true' liItem 1/li liItem 2/li liItem 3/li /ol By default none of this elements are focusable, correct? Not without the contenteditable= attribute, no. If I bind an onFocus/onBlur event handlers on the OL element, both get triggered when I click on it and off it... Which means that it became focusable due to the contenteditable attribute! The editing host (the ol element) is focusable, otherwise it wouldn't be editable, yes. Going further, if I turn the LI elements focusable by adding the tabindex='-1' attribute and also bind onFocus/onBlue event handlers on them, when I click any LI item, here is what is currently happening: - In Chrome (can't remeber version), this is the event order: LI's onFocus - LI's onBlur - OL's onFocus; - In Firefox (can't remeber version), the only event triggered is LI's onFocus; I don't really know what it would mean to focus the li elements if the ol was already focused, really. I mean, everything that's editable has to be reachable by the cursor (i.e. focusable), right? It's just part of being editable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, 24 Sep 2010, Mounir Lamouri wrote: I agree that a child of a datalist element should not block the form submission. However, I'm wondering why do we care about this particular edge case when there are a lot of situations where an element can be invalid without any possible action from the user. If there is no specific use cases in mind I think we should just remove that. It's so that you can use a select in the datalist (with the same options) for fallback in older UAs, without that select having any effect on the form submission. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Low Memory Event
On Fri, 24 Sep 2010, Charles Pritchard wrote: Do we have a route, or DOM events that signal when the device has a low memory condition? My computer is constantly running low in memory. Mozilla-apps (thunderbird) start hiding unneeded icons; Chrome betas just go ahead and crash the active process. Mobile platforms all have such low memory hooks for their apps. They're necessary to allow designers to add additional logic to handle the condition by releasing buffers, serializing data, using localStorage, etc. For practical reasons, we can't really constrain user agents in situations related to hardware limitations. Different platforms have different ways of dealing with these situations and it's not always possible for a user agent to comply with specific requirements. (For example, when running out of memory, the UA might no longer be able to spin up the JS interpreter.) On Mon, 27 Sep 2010, Rob Evans wrote: I think one of the most useful things that a js script could know is how much memory is available and how much the current page is using. I'm writing a js game engine and knowing how much I can safely site in memory would be incredibly useful! That way I can do everything to maximize engine performance. I could determine how large I could make a canvas element, how much data I can store client side in arrays or if need be, switch to asking the server for data more often and storing less client side. Please don't use all my memory for your Web-based game. :-) I may just be running it in the background while finding a video to watch, for example, in which case I really don't want the game using all my resources. Also, resources tend not to be as simple as the above could describe. For example, right now you could allocate 3 GB of RAM on this machine without any difficulty, you could allocate 6 GB if you're willing to wait for other apps to be paged out, and you could allocate 12 GB if you're willing to have your RAM be backed by a slower medium (like disk), thrashing like crazy. But that's right now; maybe while you're getting the 3 GB of data set up, some other app will allocate 20 GB and will evict you entirely out of the computer. And maybe when you create a 100-character string in one browser it actually takes just 100 bytes, but on another browser it might take 1000. So not only would the information be unreliable, it would be insufficient to really make good judgements. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] self-closing tags in html5
On Sat, 25 Sep 2010, William F Hammond wrote: In the spec at 8.1.2.1 (6) (for the text/html serialization): Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing. It would be better to allow self-closing tags on all de facto empty elements, foreign or not and defined-empty or not. In http://lists.w3.org/Archives/Public/public-html-comments/2010Sep/0027.html you further clarify de facto empty as meaning: | A defacto empty element is an element that is either defined-empty in | the document type definition OR any element in the current document | instance that has no content. While syntactic sugar to make foo/ equivalent to foo/foo even for elements that are not void elements would probably be quite popular, it is unfortunately incompatible with legacy content. It turns out that there is a large amount of content that includes / characters in positions that appear to be the end of the start tag but that do not intend to have the browser close the element immediately. For example, markup such as the following is sadly common: p/Hello world!/p I have therefore not changed the spec in response to this request. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
