[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
[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
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
Re: [whatwg] Proposal: Allow block content inside label element
On 5/8/07, Martin Atkins <[EMAIL PROTECTED]> wrote: For this reason, I certainly wouldn't mind label allowing block-level children. Both Opera 9 and IE6 (the only browsers I have handy to test right now) already support DIV as a child of LABEL correctly, per Hixie's DOM viewer.[2] [...] [2] http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0D%0A%3Clabel%3E%3Cdiv%3Edsfgdsfgsdfgsdf%3C/div%3E%3C/label%3E Interesting, now I'm seeing the same (it works) in Firefox. I was developing an app a few weeks ago where the browser (Firefox) was refusing to put the textarea inside the label. I'll have to figure out exactly what was triggering it. That said, if people are amiable to this pattern I think some specific spec text could help clarify it. Thanks. -- 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] versus |cite|
On 1/12/07, Matthew Raymond <[EMAIL PROTECTED]> wrote: | | How times have changed, said | | http://ln.hixie.ch/?start=1163122250&count=1";> | Ian | | . | Looks useful and reasonable to me, though I'd drop the superfluous hash (#) in the |cite| attribute. Then it would be more akin to |for| from . | ... | How times have changed, said | | ... I definitely agree that something has to be done to make |cite| and useful. With this method, user agents could provide additional functionality like automated citation lists and controls (e.g. linking to citations from quotes). -- 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 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: The following links should be focused in the order which the link text indicates: first second forth third fifth last 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()
On 2/4/06, Jim Ley <[EMAIL PROTECTED]> wrote: > On 2/4/06, Brad Fults <[EMAIL PROTECTED]> wrote: > > I can't believe that you're so insistent upon this extremely narrow > > set of use cases and that there aren't any other popular use cases for > > getElementsByClassName(). > > It's the only one that's ever been voiced without the extreme > prompting now generating some.The WHAT specifications (like the W3 > specifications, indeed most specifications) are creating features, and > never voicing why they're necessary, the use cases are simply not made > - there probably are use cases for them, but they _must_ be voiced, > otherwise you simply cannot review them. > > > The requirement for a loaded document is to be expected when one > > wishes to manipulate the constructed DOM from that document. > > No such requirement exists in web-browsers today, why are you suddenly > inventing it? My mistake. Replace "document" with "element" and you'll have my intended meaning. That's not a suddenly invented requirement, as is demonstrated with both getElementById() and getElementsByTagName(). > > I want my designer to be able to specify an arbitrary set of elements > > in the markup for a web app that are to be "widgets". Now if the web > > app is sent out to a client that supports function X, I want to > > construct this X-widget around each of the elements in the set > > previously defined. > > This use case is fulfilled by the -moz-binding and similar proposals, > it does this more successfully (as it does not lead to the > inconsistent UI problem) I don't see the point in having both > className selectors and -moz-binding XBL approaches, I fully admit the possibility that this may be better accomplished with some other theoretical and/or vendor-specific technology, but you again missed the core point. The utility and power of getElementsByClassName() is derived from the same exact vein that both getElementById() and getElementsByTagName() derive theirs. If they are useful, then getElementsByClassName() is also useful because it gives an author *more control* over the DOM for solving the *same types of tasks*. Your elusive use case already exists in the use and abuse of the other two aforementioned functions. Now if you want to debate the utility of either of these two existing DOM functions, I think you will meet a much larger and strongly opposed group of authors who depend on and use getElementById() and getElementsByTagName() on a daily basis. The reasons why XBL is not currently an acceptable substitute are numerous, including its extremely limited implementation, its separate and higher learning curve, and the fact that it doesn't hurt anyone to have two methods to accomplish similar tasks, especially when one of them lies within a completely different tool set. > but thanks for > the details. Furthermore, your haughty and dismissive tone is neither appreciated nor necessary in a discussion such as this. > > Now that we can get past "why" we're specifying such a function, I > > feel the need to reiterate the constraints on its specification, > > but we can't know the constraints until we know why we're specifying it... > > > 2. getElementsByClassName() must be *binding language* agnostic. That > > is, we cannot assume that it will only be used in JS. > > I don't agree that it's necessary to do this, one of the historic > problems of the DOM in the ECMAScript context (and others) is that > individual language strenghts are not gained. There is nothing > obviously wrong with having language specific API's. I agree. However, as far as I'm aware, we're not defining a binding language API, but rather the core DOM components to which such an API would provide a language-specific interface. > > If getElementsByClassName() receives an array (synonymous with list), > > which all binding languages I am aware of are capable of supplying, > > Do some binding languages not require the type of the parameter to be > specified as either an array or a string? I presume that all binding languages considered can either accomplish method overloading or else use dynamic typing, either of which would make this possible. If there are cases where this is not true, let them be stated and then further examined here. Without such cases I will continue to (reasonably) assume that any binding languages will be able to deliver this functionality. > I do not personally see the use case for a class specific operator, > either a CSS Selector method, that selects on any CSS selector, or > nothing seems appropriate. With all due respect, whether you personally see the use case for a
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] getElementsByClassName()
hat
is, we cannot assume that it will only be used in JS. It should be
designed, as with all of the other DOM functions to my knowledge,
without special features which are specific to any one binding
language. That said, I believe a variable number of arguments is
completely out.
3. getElementsByClassName() should succeed as expected in the simplest
use case. From our use case above, this means calling
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:
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] getElementsByClassName()
I see this is still an open issue[1]. Is this now implemented as #1 (space-delimited class names to match)? I suggest either going with the space-delimited approach (as it's language-agnostic and well-defined at least) or with Aankhen's suggestion of a single array argument. I think the latter is better and more intuitive in design, however. The function should take a single argument at all times. If the argument is a string, that string is used as a single class name and matched against the elements in the document. Else if the argument is an array, each element of the array is taken as a string and will be treated as a class name. The elements which have all of the class names existing in the array will match and be returned in the NodeList. Thoughts? [1] - http://whatwg.org/specs/web-apps/current-work/#getelementsbyclassname On 9/5/05, Lachlan Hunt <[EMAIL PROTECTED]> wrote: > Jim Ley wrote: > > On 9/5/05, Lachlan Hunt <[EMAIL PROTECTED]> wrote: > >>I may not be understanding what you mean, but if optional parameters > >>aren't language independant, shouldn't it be defined in a more language > >>independant way, so that any non-ECMAScript languages can still > >>implement this? > > > > Yes, DOM currently is language agnostic, however the optional > > className parameters aren't compatible with languages which can't do > > that. So as defined now getElementsByClassName would not manage to do > > that. > > In that case, should it be redefined as: > >NodeList getElementsByClassName(in DOMString classNames); > > where classNames is a string of space separated class names? That would > be just as easy to implement and would work with languages that don't > support optional parameters. > > -- > Lachlan Hunt > http://lachy.id.au/ > > -- Brad Fults NeatBox
Re: [whatwg] W3C's Rich Web Client Activity and Web Application W/G
I would implore the W3C to officially denounce vapor terms such as "DHTML", "Ajax", and "Web 2.0" inside its new WGs. It helps no one when vaguely defined marketing buzzwords are used to describe very specific technologies and methods, much less in a standards-producing environment like the W3C. Two short reads on this topic: http://ln.hixie.ch/?start=339822&count=1 http://www.glazman.org/weblog/dotclear/index.php?2005/09/29/1275-bullshit Thanks. -- Brad Fults NeatBox On 9/23/05, Channy Yun <[EMAIL PROTECTED]> wrote: > Dear whatwg folks, > > At last W3C announced a charter of Web Application W/G and Rich Web > Client Activity Proposal. As you know, this activitiy will be started > in September, 2005. According to charter, they included standardzation > of all RIA technology (XUL, XAML, MXML, XBL and APIs) and combination > with server programming (ECMAScript including Ajax, C#, Ruby etc.) And > this working group consists of Format Task Force, API Task Force and > Common deliverables. They have a plan of Ajax standardization with DOM > w/g. > > How about this action? I wonder whatwg's action to this activity. > > Channy > > Mozilla Korean Community > http://www.mozilla.or.kr >
