[whatwg] HTML5 Feedback: Section 3.5.2 Focus
A few things in Section 3.5.2: There is always an element focused; in the absence of other elements being focused, the document's root element is it. [1] This sentence is awkwardly worded and as far as I can tell, document's root element is referenced but not defined anywhere. It might be better as something like: There is always a single element with focus. If no other element in the document has focus, focus is given to the document's root element -- in this case the body element. That is assuming, of course, that the body element is indeed the element that is to receive focus when no other element is focused. I'm not thrilled with this wording either, but it is an incremental improvement in comprehensibility. If no element specifically has focus, this must return the body element. [2] This sentence references the body element (with proper linking to its definition). Is the intention here to distinguish the body element from the document's root element mentioned in the previous quote? If so, it's not clear what the distinction is or why it is present. If not, these two sentences should use the same terminology. [1] - http://www.whatwg.org/specs/web-apps/current-work/#focus [2] - http://www.whatwg.org/specs/web-apps/current-work/#activeelement -- Brad Fults
[whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view
There are a couple of problems I have found in this section. If it isn't possible to show the entire element in that way, or if the argument is omitted or is true, then the user agent must instead simply align the top of the element with the top of the viewport. [1] I have two issues with this text: 1. The word simply is rhetoric and doesn't seem reasonable or useful in the context of this part of the specification. 2. It may not be possible to align the top of the element with the top of the viewport without scrolling past the bottom of the document, so the must is unreasonable. This contingency should be mentioned (scrolling past the bottom of the document is not, as far as I know, desired). Secondly, with respect to this section as a whole, I see no description of necessary behavior for horizontal scrolling. Surely this is an issue that must be addressed, as it would be decidedly deficient if scrollIntoView() only took vertical scrolling into account, leaving horizontally overflown content still outside of the viewport after the method's invocation. [1] - http://www.whatwg.org/specs/web-apps/current-work/#scrollintoview -- Brad Fults
Re: [whatwg] HTMLFormElement reset method
Bumping this in hopes of a response. Thanks. On 3/29/07, Brad Fults [EMAIL PROTECTED] wrote: In section 7.1 of the WA 1.0 draft [1], there is the following text: The reset() method resets the form, then fires a a formchange event on all the form controls of the form. In the case of a form seeded with initial values [2], it is not clear to me whether the intention is for the form's reset() method to reset the form to some sort of blank state or to the state immediately following the seeding of initial values. Clarity on this point would be appreciated. Thanks. [1] - http://www.whatwg.org/specs/web-forms/current-work/#form.checkvalidity [2] - http://www.whatwg.org/specs/web-forms/current-work/#seeding -- Brad Fults -- Brad Fults
[whatwg] Proposal: Allow block content inside label element
Currently, as far as I can tell, in HTML 4 [1] and HTML 5 [2], the label element is defined as having inline content. When using the implicit form control association pattern described in the HTML 4 spec (e.g. a form control inside of the label element instead of or in addition to using the |for| attribute), this becomes a problem. Specifically, if one tries to place a textarea element inside of a label element, modern browsers will insert the textarea as a later sibling to the label in the DOM instead of as a child. This seems to be due to the fact that the textarea is a block element and that label can't contain it according to the spec. Could we remedy this by allowing block content inside of a label element? Thanks. [1] - http://www.w3.org/TR/html401/interact/forms.html#edef-LABEL [2] - http://www.whatwg.org/specs/web-apps/current-work/multipage/section-forms.html#the-label -- Brad Fults
[whatwg] HTMLFormElement reset method
In section 7.1 of the WA 1.0 draft [1], there is the following text: The reset() method resets the form, then fires a a formchange event on all the form controls of the form. In the case of a form seeded with initial values [2], it is not clear to me whether the intention is for the form's reset() method to reset the form to some sort of blank state or to the state immediately following the seeding of initial values. Clarity on this point would be appreciated. Thanks. [1] - http://www.whatwg.org/specs/web-forms/current-work/#form.checkvalidity [2] - http://www.whatwg.org/specs/web-forms/current-work/#seeding -- Brad Fults
Re: [whatwg] [WebForms2] custom form validation notifications without scripting
On 10/3/06, Joao Eiras [EMAIL PROTECTED] wrote: Although WebForm2 provides automatic validation of form content from the UA side, the specification has a few gaps related to customizablility of notifications, by web authors, without scripting enabled. If the user fills a form in an improper way the UA should alert him of the problems. Opera in the early days of its initial web forms support showed an alert box stating that the information was invalid, now it flashes the input field, and presents a message overlapped in the webpage. However it presents a very generic error message like You must set a value! (for required) or foo is not in the format this page requires (for pattern). The author may want, in the case of an error, to present its custom error message to the end user. This could be achieved by declaring new custom attribute for the several controls, which could hold the message. The UA could then either pop up that message to the user or embed it in the page (like Opera does currently). The attribute could be named like requirederr, patternerr, or use some other sort of naming convention to easily associate the constraining property with the message attribute. Is the use of the title attribute inappropriate for this case? -- Brad Fults
Re: [whatwg] Scoped tabindex proposal
On 9/1/06, Aaron Leventhal [EMAIL PROTECTED] wrote: Don't try to overload the tabindex attribute. First, the browsers currently optimize it knowing that it's an integer. Second, the scoping is orthogonal. Third, magic values are less readable. It's voodoo. Yes, yes, and yes. Completely agreed. -- Brad Fults
Re: [whatwg] Scoped tabindex proposal
Interesting proposal. I think it's a useful suggestion, but it may be easier to add another attribute that controls the scoping, rather than trying to overload |tabindex|. Something like table tabaccess=scoped could work. In this case, tabaccess=global (or something equivalent) would be the default. -- Brad Fults NeatBox On 8/31/06, Simon Pieters [EMAIL PROTECTED] wrote: Hi, Currently if you want to use the tabindex to change the tab order you mostly have to specify tabindex on all links and form controls prior to the area you want to modify the tab order, because otherwise that area would be before all prior elements in the tab order, which in most cases isn't wanted. Therefore there's a need to scope tabindex somehow. So here's an idea. A new value for the tabindex attribute, scoped. Here's an example: pThe following links should be focused in the order which the link text indicates: pa href=#first/a table tabindex=scoped tr tda href=# tabindex=1second/a tda href=# tabindex=3forth/a tr tda href=# tabindex=2third/a tda href=# tabindex=4fifth/a /table pa href=#last/a The table itself is not in the tab order and is not focusable. I'm not sure if we need another attribute or something for this instead as .tabIndex is a long and not a DOMString. Or perhaps we could say that all elements that have a tabindex attribute is a scoping element, so that authors can use tabindex=-1 on the table instead. Here's a pointer of where this (or something similar) is called for: http://accessifyforum.com/viewtopic.php?t=6034 Regards, Simon Pieters
Re: [whatwg] Summary in lists
It isn't clear why the `title` attribute[1] wouldn't fulfill this desire. Any elaboration or use cases would be helpful. Thanks. [1] - http://www.w3.org/TR/html401/struct/global.html#adef-title -- Brad Fults NeatBox On 6/12/06, Isac Backlund [EMAIL PROTECTED] wrote: Hi, I think that the summary attribute should be an optinal attribute on the dl, ul, ol and menu element. And why? Becouse i would like to have an attribute that summarizes the content in the list. What do you guys and girls think about that? /icaaq
Re: [whatwg] getElementsByClassName()
On 2/5/06, Ian Hickson [EMAIL PROTECTED] wrote: I can certainly see myself speccing a getElementsBySelector() API as part of Selectors 2. But either way, the spec for gEBS is simple; it returns the same type as getElementsByTagName(), it is accessible from Document and Element nodes and selects a subset of the descendants of that node, it takes a single argument (a string representing a selector), its first version doesn't support namespaces, and it raises an exception SYNTAX_ERR if the string can't be successfully parsed by the UA. If this is anywhere in the near future, I'm all for dropping getElementsByClassName() in favor of this broader solution. But if this is high in the sky and won't be seen for years to come, I'll take the former sooner. What will it take to kick start the process for getElementsBySelector()? I suppose a few browser implementations would be good fuel. -- Brad Fults NeatBox
Re: [whatwg] getElementsByClassName()
document.getElementsByClassName(x-widget) returns all elements containing the class x-widget -- never mind which other classes those elements have. Taking all of these constrains in mind and the further desire to aggregate multiple sets in a terse and powerful fashion, I recommend the array-based approach. If getElementsByClassName() receives a string, it is to treat that string as a class name and match all elements which contain that class name. If getElementsByClassName() receives an array (synonymous with list), which all binding languages I am aware of are capable of supplying, it treats each entry of the array as a string and matches all elements containing *all class names* specified in the array, regardless of which other class names each element might have. So in HTML + JS, this behavior would play out as follows: a class=Z id=e1 / a class=Y Z Q id=e2 / a class=A B C id=e3 / a class=Q P C id=e4 / document.getElementsByClassName(Z) gives e1, e2 document.getElementsByClassName(P) gives e4 document.getElementsByClassName(F) gives nothing (null/nil/etc.) document.getElementsByClassName([Z, Q]) gives e2 document.getElementsByClassName([P, B]) gives nothing (null/nil/etc.) Sorry for the length, but I believe this is a fair summary of a valid use case, the constraints on design, and a design candidate which satisfies those constraints well. Thank you. -- Brad Fults NeatBox
Re: [whatwg] introduction, plus some form input ideas
On 1/30/06, Ric Hardacre [EMAIL PROTECTED] wrote: hello, i'm an asp developer in the uk and have a couple of suggestions... no doubt selfishly to make my life easier one day :-) these could probably do with their own threads if they're deemed worthy of discussion but let's just throw them out there: 1. form tag: send=all , (default, send all fields to server in get/post) send=changed , only send hidden fields and fields that have been changed by the user Agreed, this is useful. Details of the implications of this, however, I am not so sure of. the idea being that if i'm running a datagrid then there's no point sending a ton of data back and forth if the user only edits a couple of cells. but the hidden form data will still be needed in any case so i can still connect the data sent to the user who sent it! 2. select tag: selectedindex=[num] Agreed. This would be very useful. implicitly set the selected index, instead of having to parse all the option tags and insert a selected string, much easier to bind to server side data, an invalid value (such as -1 or greater than the number of option tags) would mean none are selected. this would obviously not apply to multiple-selects 3. input tags: validate=[regex] See: http://whatwg.org/specs/web-forms/current-work/#the-pattern -- Brad Fults NeatBox
Re: [whatwg] Drag and drop in HTML5
On 5/6/05, Brad Fults [EMAIL PROTECTED] wrote: :draggable = DOM element that has .draggable=true (or whatever is decided on) :dragging = DOM element that is being dragged (perhaps opacity: 0.5) :dragging:droppable = DOM element that is being dragged and can be dropped over its current location :dragtarget / ? = container that allows for the current dragging element to be dropped upon it (border: 2px dotted red) :dragged = the original DOM element that was dragged, in its original position (it would be up to script to determine whether or not to remove it or whatever else) After thinking about it more, it seems that this list is incomplete. :dragtarget:droppable = the currently dragging element can be dropped over this element. (border: 2px dotted green) And instead, make :dragtarget generic for all drag targets for the currently dragging element. :dragtarget = a valid drag target for the currently dragging element--the dragging element is in this drag target's droppable list. (border: 2px solid blue)-- Brad FultsNeatBox
Re: [whatwg] Editing
On 4/20/05, Anne van Kesteren [EMAIL PROTECTED] wrote: Besides your other points I think it would also be important to specify the content model the element can have and the possibility to restrict this content model. ... em contentEditable=true exclude=a em strong span Although such a selection method would be convenient, I think it makes more sense to specify such exceptions on the elements themselves, removing the need to add a new attribute. For instance, div contenteditable=true a href=#header contenteditable=falseHeader/a a href=#footerFooter/a /div In this case the first link would be manipulated as an unbreakable unit inside the div. -- Brad Fults NeatBox
