Re: [whatwg] Why [PutForwards=value] for htmlFor output element attribute ?
On 08.04.2010 16:07, Olli Pettay wrote: On 4/5/10 3:21 PM, Mounir Lamouri wrote: Hi, I'm wondering why the [PutForwards=value] extended attribute is needed for the htmlFor output element attribute ? It is making things pretty ugly for a need I do not really get. Thanks, -- Mounir I agree. In general PutForwards makes APIs strange, IMO Location is a good example of a pretty awkward API. In the case of output element, element.htmlFor.value = "Something" isn't really more difficult than element.htmlFor = "something"; Though, .htmlFor accept setting a string value in other interfacase, but in those cases the type of the attribute is DOMString. It is a bit ugly that one .htmlFor is DOMSettableTokenList, but other .htmlFors are DOMStrings The PutForwards attribute mitigates this problem, by letting you treat the property as if it were a DOMString if you want. You could argue that every DOMSettableTokenList should have PutForwards=value behavior by default, since it already forwards on getting. Would be at least great to know some good reasoning for using PutForwards. Btw why doesn't .classList have PutForwards (in which case it could use DOMSettableTokenList) Direct access to the raw class attribute already exists as .className, so there's no need. -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
[whatwg] Input type attribute reflection
4.10.7 "The type attribute controls the data type (and associated control) of the element. It is an enumerated attribute." "The accept, alt, autocomplete, max, min, multiple, pattern, placeholder, required, size, src, step, and type IDL attributes must reflect the respective content attributes of the same name." 2.7.1 "If a reflecting IDL attribute is a DOMString whose content attribute is an enumerated attribute, and the IDL attribute is limited to only known values (...)" "If a reflecting IDL attribute is a DOMString but doesn't fall into any of the above categories, then the getting and setting must be done in a transparent, case-preserving manner." The input section does not specify that @type is limited to only known values. I assume this is so to allow extensions with new input types to work properly. However, this also means get/set operations on .type are not allowed to normalize case for known values, and that the missing value default does not apply to .type. === 4.10.7 "The missing value default is the Text state." 'Missing value default' is not linked to the definition. Yes, it is quite close to the sentence saying @type is an enumerated attribute, but there is a huge table between them, breaking the flow. -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
Re: [whatwg] an odd example of the meter element
Futomi Hatano wrote: Hi, all I found an odd example in the meter element section of the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-meter-element max: 100; current: 75 According to "steps for finding one or two numbers of a ratio in a string", does it means that the actual value is 100 and the max value is 75? http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#steps-for-finding-one-or-two-numbers-of-a-ratio-in-a-string If so, the gauges would end up looking maxed out. Should it be as below? current: 75; max: 100; Thank you. No, the larger number is always used as the max, and the smaller as current. In the meter section: "(...) if there were two numbers parsed out of the textContent, then the maximum is the higher of those two numbers." and "(...) if the result of processing the textContent of the element was two numbers, then the actual value is the lower of the two numbers found." -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
[whatwg] Web storage NameCreator
The Web Storage spec's Storage interface uses setItem as NameSetter only. It should be both NameSetter and NameCreator, otherwise it's not possible to create new entries with property access. -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
Re: [whatwg] WF 2.0 -- HTMLTextAreaElement [ type ] attribute
On Fri, 14 Sep 2007 02:52:33 +0200, Garrett Smith <[EMAIL PROTECTED]>
wrote:
Regarding the [type] attribute:
interface HTMLTextAreaElement : HTMLElement {
attribute DOMString defaultValue;
readonly attribute HTMLFormElement form;
attribute DOMString accessKey;
attribute longcols;
attribute boolean disabled;
attribute DOMString name;
attribute boolean readOnly;
attribute longrows;
attribute longtabIndex;
readonly attribute DOMString type;
What does the |type| attribute do?
Input has .type, to mirror the attribute. The fact that both select
(redundant with .multiple) and textarea (always the same) also have .type
suggests to me it was intended to allow a unified view of all form
controls. You can check .type directly without having to bother with
checking the .tagName or similar first.
--
Magnus Kristiansen
"Don't worry; the Universe IS out to get you."
Re: [whatwg] List captions
On Fri, 06 Apr 2007 14:31:58 +0200, Andy Mabbett <[EMAIL PROTECTED]> wrote: How often do we see something like: Animals: Cat Dog Horse Cow This would be more meaningful as: Cat Dog Horse Cow There could also be a summary attribute, as with tables. Any interest? We should do our best to avoid repeats of alt, title, and friends. A list header would go much better as a separate element, like is for tables. The resurrection of was proposed a few days ago on this very list, why not take a look at that thread? -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
Re: [whatwg] : togglePause() versus pause()
On Sun, 18 Mar 2007 22:00:33 +0100, Anne van Kesteren <[EMAIL PROTECTED]> wrote: Hi, I just played some more with our internal implementation (Opera's) and noticed that our pause() really is like togglePause() in the HTML5 proposal. Looking at the specification I don't see much need for pause() there. Perhaps togglePause() should just become pause() and pause() be removed? I would suggest the opposite. For basic actions like play and pause, play() and pause() are the most natural options. I question whether we need a command to toggle between play/pause at all. Any UI which uses a combined play/resume button has to know which state it is, so it already knows which command is relevant. -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
Re: [whatwg] Video proposals
On Fri, 16 Mar 2007 04:39:07 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote: ON PLAYLISTS On Mon, 30 Oct 2006, Shadow2531 wrote: The handler should also support some type of playlist like <http://www.xspf.org/>. On Mon, 30 Oct 2006, Charles Iliya Krempeaux wrote: #3: Playlists. (A single video file just won't cut it.) These were the only requests for playlists. Could you elaborate on the use cases for playlists? What are the needs for playlists? When I think of playlists, the first thing that comes to mind are commercials. Some video sites show ad or promotion clips before and/or after the main video. I imagine they'd see that as a use case. It could also be used to create medleys of several smaller clips, although it might not be a big need. -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
Re: [whatwg] Adding mouseenter and mouseleave events
On Thu, 15 Mar 2007 20:10:33 +0100, Gareth Hay <[EMAIL PROTECTED]> wrote: I'm not so sure it is a workaround though. If you know that the event will bubble, you can make your handler prevent bubbling. I don't think we should be adding two new events to a spec, when the existing events can work in the way you want, albeit with a line more code. If we did, we'd be forever adding very specialized events. You don't seem to understand the situation. Imagine there's a parent element and several child elements. Every time you mouse over a child element, a mouseover event triggers (and mouseout on the previous element). This event bubbles up until it reaches the parent element. An event handler on the parent can only prevent the events from bubbling event further (which is not relevant), not from reaching itself. To prevent it using bubble cancelling you would have to attach events stopping bubbling to every child element of the target. Not only is this an unreliable way of doing it, it also interferes with potential other elements which actually want bubbling. The other, more practical workaround is to look at each incoming event and check "did this one come bubbling up, or does it belong here". However, workarounds do not solve the problem itself. With mouseenter/leave, there is no bubbling. There is no need to attach handlers to arbitrary elements, and no need to manually check each incoming event to see if it's bubbling or direct. These events are linked to a significant enough use case. They are no more redundant than existing events like click (mousedown+mouseup) and keypress (keydown+keyup). -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
Re: [whatwg] Adding mouseenter and mouseleave events
On Thu, 15 Mar 2007 02:02:46 +0100, Gareth Hay <[EMAIL PROTECTED]> wrote: On 15 Mar 2007, at 00:30, Magnus Kristiansen wrote: Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseenter.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/ events/onmouseleave.asp Can't you just return false from an event handler to prevent further bubbling? As mentioned there are workarounds, although I don't think attempting to add anti-bubbling handlers on every descendant element is a reliable one. This unwanted bubbling puts extra load on the user agent for processing it, and the script author to work around it, when removing the root cause is easily possible by making the event non-bubbling to begin with. -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
[whatwg] Adding mouseenter and mouseleave events
Mouseover/out events will trigger when elements contained inside the EventTarget are hovered, and then bubble up. This is contrary to the most obvious interpretation, as you are still inside (over) the targeted element. IE supports two events, mouseenter[1] and mouseleave[2], which solve this problem by not bubbling. It is possible to work around the problem by using target/relatedTarget and walking up the DOM tree. However, this requires extra code for every event handler. Besides, these events were often not meant to be generated in the first place, by the intent of the author. I have no statistics for how often mouseover/out are used with and without intent of bubbling, but the anecdotal evidence from my own experience has never found me wanting it. I suggest these two events be added to the web applications spec. [1] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseenter.asp [2] http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmouseleave.asp -- Magnus Kristiansen "Don't worry; the Universe IS out to get you."
