[whatwg] HTML inputs directly toggling CSS classes on elements?
A few days ago, I dipped my toes into web design again for the first time in a while. One of the results is the CSSClassToggleHandler constructor from [1]. Basically, it takes an radio button or checkbox, and turns that input into a toggle for a CSS class on another element. This is relatively easy to do in JavaScript, as the very short function illustrates. I wonder out of simple curiousity if anyone's considered defining a short set of attributes to do this in HTML itself, without requiring JavaScript. Three attributes on the input would be all that's necessary: - cssClassName="(word)" would be the class name to apply - cssClassFor="(id)" would be an IDREF to the element which would apply the class - cssClassNot="true" would invert the class enable/disable (so that if the input is checked, the class would be removed instead of applied) I'm of two minds about this. On the one hand, if HTML can provide a reference from an input to an element the input is intended to influence, that has to be useful for reasons similar to the HTML label element's for attribute, and it makes for one less dependency on JavaScript. (Accessibility?) On the other hand, the modern Web has so much dependency on JavaScript. Also, the HTML input element has a horrendously long list of attributes on it already. So, I thought I'd throw the idea out there and see if anyone likes it. Alex [1] https://github.com/ajvincent/es7-membrane/blob/master/docs/distortions-gui/stylesheet.js#L13-L26 -- "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- Alexander J. Vincent, June 30, 2001
[whatwg] Verbosio 'template DOM' - breaking the rules for a reason
Over the last six months, I've quietly toiled away at an alternate DOM implementation for my Verbosio editing project. (Verbosio is a project for building a prototype XML editor, with XML languages supported as Firefox-like add-ons.) I would have preferred to use Mozilla's native DOM or a pre-existing DOM implementation like domjs or envjs, but unfortunately I felt that these would not meet my requirements - shadow content adjacent to the owning content, XML entity support and undo history management. I also felt that I could not at the time easily adapt any of them to my needs. (I'm aware of work ongoing in shadow content and undo history, but these specifications and implementations aren't mature yet.) So, being the mad scientist that I am, I built my own template DOM from scratch. It's nowhere near compliance with the DOM Living Standard ( http://dom.spec.whatwg.org/ ), nor do I intend it to be. I'll be using my template DOM in parallel with the Mozilla DOM - the former only for managing XML templates and XML entity references in Verbosio, the latter for rendering those templates and for ordinary DOM work. In particular, I've started a few wiki documents on my project's website where I explain what's supported, what's not supported, and why: https://sourceforge.net/p/verbosio/templates/wiki/DOM/ https://sourceforge.net/p/verbosio/templates/wiki/Infrastructure/ https://sourceforge.net/p/verbosio/templates/wiki/Build/ Currently, my Jasmine testing framework reports over 900 tests - most of which I'm certain the current DOM test suites already cover. The remaining tests are specific to my implementation and would likely not apply to other existing DOM implementations. In terms of merging my own work or ideas with other DOM implementations and specifications - I'm certainly willing to consider it, but I need this template DOM to work in my Verbosio editing project first. I'm posting to this mailing list primarily as a heads-up, to show where I'm going in the short term and perhaps to see if some of my approaches and algorithms could be useful to others in this space. The project's code is available under the Mozilla Public License version 2. Alex Vincent Hayward, CA, U.S.A. Planet Earth, Milky Way Galaxy, the Universe (roughly) -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Exceptions in UndoManager
My first concern is what state will the UndoManager be in when an exception happens? There may be transactions that were undone, cropped off On Wed, May 30, 2012 at 12:03 AM, Ryosuke Niwa rn...@webkit.org wrote: When an exception is thrown within transact(), the most sane behavior appears to be rolling back all DOM changes that have made thus far (this in turn may also fail due to mutation events, etc...). Also this is not possible with manual transactions because browsers don't keep track of what's happening in the DOM, etc... So how about just firing an event like DOMTransactionException at the undo scope host to let scripts handle them? -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Exceptions in UndoManager
Sorry, I hit send prematurely. Let me try again in a few minutes. On Wed, May 30, 2012 at 8:15 AM, Alex Vincent ajvinc...@gmail.com wrote: My first concern is what state will the UndoManager be in when an exception happens? There may be transactions that were undone, cropped off On Wed, May 30, 2012 at 12:03 AM, Ryosuke Niwa rn...@webkit.org wrote: When an exception is thrown within transact(), the most sane behavior appears to be rolling back all DOM changes that have made thus far (this in turn may also fail due to mutation events, etc...). Also this is not possible with manual transactions because browsers don't keep track of what's happening in the DOM, etc... So how about just firing an event like DOMTransactionException at the undo scope host to let scripts handle them? -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001 -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Exceptions in UndoManager
1. What state will the UndoManager be in when an exception happens? There may be transactions that were undone, cropped off by the transact() call, which per the spec are now unrecoverable. Also, in the undo or redo cases, we might be in the middle of a merged transaction. The spec says we can't call undo while we're unapplying a transaction... nor can we call redo. So where will we be - both during the event dispatch and in the aftermath? 2. What information about the exception will be included with the event - or with the UndoManager? 3. If the UndoManager can recover somehow to a known good state without intervention, how can it indicate that - and possibly, what that good state would look like? 4. If no recovery is completed, is it acceptable to mark the UndoManager in an error state and prevent further transactions from either happening or being recorded until both undo and redo stacks have been completely cleared? (I'm thinking of a fatal error state, which can be recovered if you throw away all your history.) 5. If there is a recovery by one event listener, should another event indicating that recovery be dispatched, so that earlier event listeners are aware of the new good state? I can write up a simple HTML + SVG document illustrating the UndoManager Exception cases I can dream up, if anyone's interested. There's four main areas: during transact with no undone transactions, during undo where we may be in the middle of a transaction group, during redo where we may be in the middle of a transaction group, and during transact where some transactions have been undone. For question 3, I would propose including an UndoManager mockup without methods: a static data representation of the default after-state. Note that it is perfectly okay in my opinion for the UndoManager to report I cannot recover from this on my own, and not provide this mockup at all. On Wed, May 30, 2012 at 12:03 AM, Ryosuke Niwa rn...@webkit.org wrote: When an exception is thrown within transact(), the most sane behavior appears to be rolling back all DOM changes that have made thus far (this in turn may also fail due to mutation events, etc...). Also this is not possible with manual transactions because browsers don't keep track of what's happening in the DOM, etc... So how about just firing an event like DOMTransactionException at the undo scope host to let scripts handle them? - Ryosuke -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] UndoManager questions
Hi, folks. I'm stubbing out a quick dirty implementation of UndoManager in JavaScript, and I have a few questions. For those not familiar, the spec lives here: http://rniwa.com/editing/undomanager.html * The spec is inconsistent in a few places. For instance, in the green non-normative section, clearUndo states: Removes entries in the undo transaction historyhttp://rniwa.com/editing/undomanager.html#undo-transaction-historybefore positionhttp://rniwa.com/editing/undomanager.html#dom-undomanager-positionand resets positionhttp://rniwa.com/editing/undomanager.html#dom-undomanager-positionto 0. However, in the normative part, it states: The clearUndo() method must remove all entries in the undo transaction history http://rniwa.com/editing/undomanager.html#undo-transaction-historyafter the undo position http://rniwa.com/editing/undomanager.html#undo-position. Note that one of these states before, and the other states after. This contradiction is not implementable. * The spec mentions a DOM transaction grouphttp://rniwa.com/editing/undomanager.html#dom-transaction-group, but does not define that. * When adding a transaction to a DOMTransaction[] as part of execute's merge being true, do we add it to the beginning or the end of the list? This matters for .item(). * Exception handling is woefully undefined in this spec: ** If my transaction throws an exception during UndoManager.execute(), how should that be handled? What happens to transaction groups that were previously undone? ** If my transaction throws an exception during .undo(), how should that be handled? ** Ditto redo. * What precisely lives at UndoManager.item(0)? The most recently completed transaction, or the oldest? * When UndoManager.execute() is called with an object not implementing .undo, or .redo, should we fire some kind of warning to the user? What should happen when we try to undo that transaction? Given all the above, I think I need to write some tests for UndoManager. Anyone mind Jasmine-based tests? -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
There's too much good stuff going on, both in the specs, and in my own
project. :-) I noticed Ehsan's blog post about editing on the Web,
http://ehsanakhgari.org/blog/2011-08-31/future-editing-web . I'm groaning
because I haven't been involved! :-p
A few thoughts on my mind:
1. I think we should start writing a test suite, for two reasons. First,
to get some idea how this works in practice, with a reference implementation
in JavaScript. That will help us iron out some of the API debates we've
been having (reapply, specifically). Second, a test suite can help all the
implementers implement the same thing.
2. I think I'm not going to fully understand this spec until I at least
try my hand at a test suite implementation, in Jasmine. :-)
3. I just spotted a flaw in our API's. Imagine the following:
-
myEditor.undoManager.transact({apply: function () {
insert(document.createTextNode('o')) }, label: 'First transaction'});
myEditor.undoManager.transact({apply: function () {
insert(document.createTextNode('k')) }, label: 'Merging transaction'},
true);
- User calls myEditor.undoManager.item(0).label. Which label does he
get back? For that matter, which transaction does he get back, and which
transaction is forever hidden from him?
- Perhaps for this reason, .item() should return a readonly
Transaction[], representing the transaction group.
4. Did we talk about a maxlength for the UndoManager? If we allow an
infinite number of transactions in an UndoManager, a lot of memory could get
eaten up. I'd say the page author should be able to limit the number of
transactions kept in memory at his or her discretion.
5. Section 2.1 is Definitions, but several of the definitions are
scattered around the specification (Transaction, for example), and do not
start with basic definitions. I think this section needs to be rewritten,
starting with the most basic definitions. (Define a transaction. Define a
transaction group based on the definition of a transaction. Define an undo
stack based on the definitions of a transaction group and a transaction, and
so on.)
6. I'm wondering a bit about localization of the Transaction object's
label. It's probably an unnecessary concern (this specification shouldn't
go too deep), but I'm just wondering how both scripted and native
transactions will detect the language of the webpage and generate
locale-specific labels. I'd like a paragraph on that, at least, even if
it's just to say localizations are outside the scope of the spec, and that
language changes while an UndoManager exists may not be supported.
Alex
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
On Thu, Sep 1, 2011 at 11:36 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Sep 1, 2011 at 6:26 AM, Alex Vincent ajvinc...@gmail.com wrote: 1. I think we should start writing a test suite, for two reasons. First, to get some idea how this works in practice, with a reference implementation in JavaScript. That will help us iron out some of the API debates we've been having (reapply, specifically). Second, a test suite can help all the implementers implement the same thing. Implementing it in JavaScript will be somewhat challenging because managed/automatic transactions need to keep track of all changes made by a function it's calling. It'll require a heavy use of mutation events (and they're going away!) Not necessarily. We can use a DOM implemented in JavaScript, a la http://www.envjs.com/. That wouldn't require mutation events, since we could customize the DOM code before running it. -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] DOM mutations, transactions and UndoManager thoughts
Thanks, Ian. I've been loosely following the UndoManager discussion - reading all the e-mails coming through. I haven't thought about it for a couple weeks, though. I'll take another look at the current draft soon. I'll need some time to come back to mutation events. Alex On Fri, Aug 26, 2011 at 3:03 PM, Ian Hickson i...@hixie.ch wrote: Since you sent your e-mail, both UndoManager and mutation events have had work done on them outside the HTML spec. UndoManager is now specced here: http://rniwa.com/editing/undomanager.html ...and is being discussed on threads in this mailing list. Mutation events are being discussed in public-weba...@w3.org. I encourage you to take part in these discussions. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction
In the last couple of weeks, I've been working with developers of CKEditor, TinyMCE, and Google Docs to come up with *new API for undo and redo*. I'd like to take a look at this and be very closely involved in this specification. About a month ago, I wrote this: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031191.html I've been working on my own prototype editor project for years (it may replace Duke Nukem Forever as king of vaporware at the rate I'm going, but I'm still working on it), and I've had some definite thoughts on undo management. API's like this interest me quite a bit. Also see https://bugzilla.mozilla.org/show_bug.cgi?id=617532 - where Mozilla is considering their own API proposals. One use case I've envisioned is an undo popup menu, where each item of the undo stack has an actual label to go with it, describing the transaction. Then you could easily see how many items you wanted to go back! I'd be happy to take this off-list, or keep it on-list, whatever you prefer. -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] input type=password... restrict reading value from JS?
This is just an idea.
For the last 10+ years, password inputs have been accessible from scripts,
with nary a complaint. If I have this code:
form action=javascript:void
div
input type=password id=pw
button onclick=alert(document.getElementById('pw').value)Show
password!/button
/div
/form
I can extract the password by clicking on the button. More to the point,
with a XHR I can send that password somewhere it shouldn't go... (well, with
cross-domain security code, maybe not, but that's not the point.)
To be honest, I can think of only two good reasons for checking a password
field's value. The first is to compare against another password field. The
second is to check the strength of the password. In both cases, JavaScript
doesn't necessarily need the actual value - if the API provides other ways
to do that.
Specifically, I would suggest two methods for this input type:
/**
* Check if a password field's value matches another.
*
* @param otherPassword Another password element.
*
* @throws Error if this.type != password
* @throws Error if other.type != password
*
* @returns Boolean True if the fields match.
*/
boolean passwordEquals(in HTMLInputElement otherPassword);
/**
* Check the strength of the password.
*
* @param type The type of check to execute.
*
* @returns 0 if dangerously low security
* @returns 1 if soon-to-be-deprecated low security
* @returns 2 if adequate security
* @returns 3 if good security
* @returns 4 if strong security
* @returns 5 if entropy-death-of-the-universe security :-)
*/
unsigned octet passwordStrength(in DOMString type);
The first idea has been suggested before:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000700.html
I don't know if the second idea has been suggested before.
--
The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own.
-- Alexander J. Vincent, June 30, 2001
Re: [whatwg] input type=password... restrict reading value from JS?
On Sun, Jul 10, 2011 at 3:21 AM, Michal Zalewski lcam...@coredump.cxwrote: For the last 10+ years, password inputs have been accessible from scripts, with nary a complaint. If I have this code: Unfortunately, the problem is not that easy to fix: denying access to the field does not prevent the attacker from changing the form submission URL after autocompletion to achieve the same... Or even simpler, changing the type attribute to something like hidden for an instant. I hate it when I don't think things through. -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] DOM mutations, transactions and UndoManager thoughts
I'm working on DOM-based editing tools in my spare time, and have been for several years. I use DOM mutation events to build transactions - objects which let me undo DOM mutations and redo them. There's a strong suggestion that DOM mutation observers should replace DOM mutation events altogether, for performance reasons. I believe a recent discussion on execCommand brought this to light again. Also, Mozilla has a bug on file (https://bugzilla.mozilla.org/show_bug.cgi?id=641821 ) to implement mutation observers which only receive a node ( http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0745.html ). For me, this presents a problem: In order to build undoable and redoable DOM transactions, I need some way of extracting a before and an after state for each individual mutation that happens. For all the ballyhoo about mutation events being evil, this is one thing that they do very well, with prevValue and newValue properties for attribute and data nodes, and with a relatedNode property for node insertions and removals. The proposed mutation observer model does not provide that information. I hope there may be some room to negotiate (either with WHATWG or Mozilla) on the interfaces. Without before and after states exposed through the DOM somehow, I can't make my editor project work, period. --- Now, I was until today unaware of HTML5's UndoManager in section 8.8 ( http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#undo). Maybe that gets me part of the way there, since it potentially tracks changes to a document. In particular, I note there's no tests or sample JS code for it written yet. I'd like to take a closer look at the interfaces there. For comparison, I'd like to mention Mozilla's nsITransaction interfaces, including nsITransactionManager - one of the nicest ideas for an editor, and one that's worked well for Mozilla's editors, including HTML inputs and textareas, for over ten years. (They're good enough that they've largely escaped attention - very few people think about the interfaces, because the editor's undo mechanism Just Works!) See http://mxr.mozilla.org/mozilla-central/find?text=string=nsITransaction for references. A few thoughts on UndoManager: * First, I really like the add() method. That sounds really useful, especially if it's scriptable, because I see myself having custom transactions which I may want to track through a document's UndoManager. * The title is even more important - it would give people a way to see a localized description of what the transaction is. Though I personally think it should not be a separate value - I think it should be a required property of the undo object. (This is one thing I actually hate about Mozilla's transaction interfaces: they didn't make it easy to label transactions.) * I'm not so sure about the remove() method. Why do we have it? If we allow removing items by index, would we want to have a splice() method that lets scripts insert items at a given index? * Naturally, UndoManager sounds a lot like nsITransactionManager. * I wonder about configuring UndoManager by script. For instance, I really want to turn UndoManager on or off by script. (Most of the time, users won't care about UndoManager, so I would think it would be disabled by default, not actively recording transactions.) Or, I may want to track attribute changes, but not node value changes. * I think a diagram clarifying the flow of actions through UndoManager would be helpful. Is it UndoManager.add(data) - data.doSomething() (which changes the document), or the other way around? How would this affect custom actions being added through UndoManager.add()? * For undo objects added by script, how would the UndoManager tell the scripted undo object to, well, undo something? Or redo something? (In particular, in such a way that the UndoManager doesn't record changes happening while the undo object changes the document in an operation.) * Is it feasible to have an UndoManagerObserver which is notified of undo objects being passed through the UndoManager (either in enabled or disabled state)? That would make it possible to manage undo objects in another context besides the UndoManager (example: I want to export undo objects to a Mozilla transaction manager, so that I drive it from there). * I'm surprised that UndoManager doesn't have a maxlength. Do we really intend to let it undo an infinite number of actions? I hope to open a debate on the UndoManager section, and on undo/redo operations in general, with this e-mail. Alex Vincent San Leandro, CA author, Verbosio XML editor project (in development hell for six years and counting!) -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] HTML 5 buttons and constraint validation
There's a possible disconnect between input type=button/ and button/. The former is barred from constraint validation, but the latter is not. (Section 4.10). Is this intentional? -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] HTML 5 clarifications on ValidityState?
I read this paragraph (from section 4.10.15.3) as self-contradicting: The validationMessage attribute must return the empty string if the element is not a candidate for constraint validation or if it is one but it satisfies its constraints; otherwise, it must return a suitably localized message that the user agent would show the user if this were the only form with a validity constraint problem. If the element is suffering from a custom error, then the custom validity error message should be present in the return value. Specifically, the last sentence contradicts the rest of the paragraph. If there is a custom error, but the element is not a candidate for constraint validation, should the validationMessage attribute be empty, or should the custom validity error message be present in the return value? You can't have both. This inconsistency is somewhat worsened when you consider the user may call input.setCustomValidity(foo) on an element that isn't a candidate for constraint validation: form action=javascript:void() input disabled=true name=foo id=foo/ /form var foo = document.getElementById(foo); foo.setCustomValidity(foo); foo.willValidate // returns false, because of the disabled attribute The willValidate attribute must return true if an element is a candidate for constraint validation, and false otherwise (i.e. false if any conditions are barring it from constraint validation). foo.validity.customError // returns true foo.validity.valid // returns false foo.validationMessage // ??? Also, I noticed the readonly attribute for input elements overrides constraint validation, per section 4.10.4.2.3 - but the readonly attribute has no meaning for several input types (section 4.10.4, the big table after the IDL). For checkboxes, radio buttons, file uploads, image inputs, submit, reset and ordinary button types for the input element, readonly has no other effect. Please advise - I'm currently working on a patch for Gecko code which implements this. -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
Re: [whatwg] Text areas with pattern attributes?
On Mon, Aug 24, 2009 at 6:04 AM, Max Romantschukm...@romantschuk.fi wrote: I really don't see a case for not allowing pattern for a textarea. The implementation side should not be that different from the same attribute on a text input? Except for the client side overhead of parsing a large amount of data against a regex, what would be the drawbacks on having pattern on textareas? Well, if the spec authors decide NOT to support the pattern attribute on text areas, I would ask the spec authors to insert a note (normative or not) explaining the rationale. Reason: I have this funny feeling I've asked about pattern attributes on text areas before. I think the question will be raised in the future. All of this has happened before, and it will happen again. -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] Text areas with pattern attributes?
I'm drifting into writing code for the pattern attribute on text fields again, and I wondered: if text inputs can have pattern attribute for regular expression matching, why not text area elements? The HTML 5 spec says: The textarea element represents a multiline plain text edit control for the element's raw value.. It might make some sense to include support for pattern validation on text areas. On the other hand, text areas could be a lot larger than standard text inputs. (There's no maxlength attribute for text areas in HTML 4.01, but there is in HTML 5.) I did a quick search on the mailing list, and I didn't see any indication this issue had been raised before. Alex -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] WF2 clarification request: File upload controls
In the past, user agents have allowed file upload controls to reference files not local to the computer in question. For validity purposes, I wonder if this should still be allowed under Web Forms 2.0. Allowing remote values in the file upload control could be a performance hit via networking, since we'd have to verify the file exists before saying valueMissing is false... -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] WF2: Clarification on valueMissing requested
The field has the required attribute set but has no value selected. In implementing this for Mozilla, I realized an edge case that could prove troublesome. Specifically, what happens if you have multiple radio or checkboxes with the required attribute and no boxes checked for any of them. Alternatively, consider when the radio button is checked but doesn't have a value... and some other radio input with the same name in the same form does have a value. There's an attempt to clarify it here: When a radio group has no checked radio button and more than one of the radio buttons is marked as required, the UA should only tell the user that the radio group as a whole is missing a value, not complain about each radio button in turn, even though all of the radio buttons marked with the required attribute would have the valueMissing flag set. Tell the user how? Visually? Through DOM events? Both, or some other way? I'm working from the DOM events view right now, and this could be the difference between dispatching one event and dispatching many. I don't require an immediate answer. Forgive me if the questions above have already been raised and discussed. Alex Vincent -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] WF2: required attribute clarification requested
For disabled or readonly controls, the (required) attribute has no effect. What does this mean? The missingValue bit of validityState is either on or off. Do I need to change the required bit if we're disabled? Or should I leave it alone? -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] Web Forms 2.0 in Gecko design document
For anyone interested in seeing WF2 implemented in mozilla.org code, I invite you to read and comment on http://wiki.mozilla.org/DOM:Web_Forms_2.0 . Please bear in mind this is intended as an internal design document, and this is very much a first draft - so it will change! -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
[whatwg] WF2: Informative style sheet appendix?
CSS 2 provides in Appendix A, and CSS 2.1 in Appendix D, non-normative references which implementers may use as a basis for styling HTML pages by default. Web Forms 2 is missing a similar style sheet for all the new features it brings to the table. For example, on my XUL Widgets project I have tentatively designated a red background to a text input as meaning This input's value is not valid according to this input's specification. I also am considering adding an icon immediately after the input, for accessibility reasons (color-blindness). A non-normative style sheet for the Web Forms 2 specification would be very useful to me as an implementer, in giving me an example to follow. As I continue to attempt implementing WF2 for Mozilla code, I think I should try to offer whatever help I can. Opinions? Thoughts? -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001
