On Mon, Nov 17, 2008 at 2:05 AM, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 30 Sep 2008, Andy Lyttle wrote:
As I understand it, it was sort of an accident that Safari supports
placeholder on anything other than search fields, but there's no reason
it shouldn't apply to all text input
On Fri, Dec 12, 2008 at 12:55 AM, Ian Hickson i...@hixie.ch wrote:
On Sun, 16 Nov 2008, ddailey wrote:
Here's the sitch: because of an extensive use of CTRL sequences in the
interface, the user will sometimes accidentally do something like CTRL R
(which the browser thinks is a refresh
I'm suggesting an addition to cross-domain (i)frames that allows scrolling
specific content into view. The use case is sites that aggregate data from
many sites (e.g. search engines) and want to display that data in an iframe.
They can load the page in an iframe, but they have no way to make the
On Fri, Apr 3, 2009 at 10:46 PM, Cameron McCormack c...@mcc.id.au wrote:
Ojan Vafai:
2) Add a css or xpath expression to fragment identifiers. Tthe iframe
src can be set to http://foo.com#css(.foo #bar). Same as above
applies. If there's no match, it's a noop. If there is a match
On Fri, Apr 24, 2009 at 2:43 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Erik Arvidsson wrote:
I do agree that the EventTarget API is suboptimal and so are most of
the DOM APIs but it is what we got and we need tie the lose ends and
make ends meet.
Why is the right approach to this to add
On Fri, Apr 24, 2009 at 6:37 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Ojan Vafai wrote:
What would be a better approach?
I believe Alex proposed some in this thread as aliases for
addEventListener. Those looked a lot better to me, for what it's worth.
I have no problem with adding
On Fri, Apr 24, 2009 at 7:26 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Ojan Vafai wrote:
If a linear list of things the event is targeting is sufficient, of
course, and we're ok with the random third argument of
addEventListener being carted around, then we might be ok using
On Tue, Apr 28, 2009 at 12:34 AM, Ian Hickson i...@hixie.ch wrote:
For implementors, the spec already gives, to the pixel, the length
required (in the rendering section).
Speaking of which, the spec isn't quite accurate to what IE does here. The
spec lists (size-1)×avg + max as the converting
SUMMARY
Currently, textareas and text inputs support the oninput event that fires
on all user-initiated modifications to their content. We should add this
event to contentEditable elements as well and add an action property the
specifies what action the user took that caused the input event.
We
On Wed, Jun 24, 2009 at 11:51 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 6/24/09 6:49 PM, Anne van Kesteren wrote:
On Wed, 24 Jun 2009 12:21:41 +0200, Olli Pettay
olli.pet...@helsinki.fi wrote:
Why would you need paste? There is paste event
(though, not properly specified anywhere, I
On Tue, Jun 2, 2009 at 11:38 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 3 Apr 2009, Ojan Vafai wrote:
I'm suggesting an addition to cross-domain (i)frames that allows
scrolling specific content into view. The use case is sites that
aggregate data from many sites (e.g. search engines
On Tue, Jul 28, 2009 at 1:01 PM, Drew Wilson atwil...@google.com wrote:
So (and forgive me for restating), it seems like hidden page addresses the
following problems that gmail and other large web apps are having:
1) Loading large amounts of Javascript is slow, even from cache.
2) Loading
On Thu, Jul 30, 2009 at 3:51 PM, Dmitry Titov dim...@google.com wrote:
This concern is clear. But what could be a direction to the solution?
Assuming one of the goals for html5 is reducing a gap in capabilities
between web apps and native apps, how do we move forward with more powerful
APIs?
I don't see what the problem here is. How is it wrong? Why can't a list be a
type of list item?
Focusing more on practicalities, every browser produces and deals correctly
with this type of HTML. Given that contentEditable is used by just about
every rich-text email or blog-posting service, it's
2009/12/11 Ian Fette (イアンフェッティ) ife...@google.com
Ok, I sense resistance to putting it in .name. What about .path, undefined
in most cases except where there is an upload including files from multiple
directories, in which case .path contains the path less any path components
common to all 3
On Mon, Dec 14, 2009 at 11:39 AM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Dec 14, 2009 at 10:33 AM, Ojan Vafai o...@chromium.org wrote:
On Sun, Dec 13, 2009 at 7:47 AM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Dec 13, 2009 at 5:36 AM, TAMURA, Kent tk...@chromium.org
wrote
On Mon, Dec 21, 2009 at 5:15 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Dec 22, 2009 at 7:21 AM, Ojan Vafai o...@chromium.org wrote:
Dealing with inconsistencies in browser behavior during typing is one of
the hardest parts of writing a sane web-based rich-text editor. We have
Currently, modal dialogs that fire during beforeunload/unload events are
used to confuse users into not being able to leave websites (e.g. to tell
the user to click on the wrong button for in the browser's beforeunload
alert dialog). They also add a layer of complexity to browser shutdown
Hickson i...@hixie.ch wrote:
On Tue, 23 Jun 2009, Ojan Vafai wrote:
Currently, textareas and text inputs support the oninput event that
fires on all user-initiated modifications to their content. We should
add this event to contentEditable elements as well and add an action
property
On Wed, Mar 3, 2010 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So I have to ask... Why are events _before_ the edit needed?
If we add these, then you have to define what happens when those event
handlers modify the state of the DOM in arbitrary ways, including carrying
out operations
What about drag-drop? I should be able to drag a directory, a file, or a
list of files onto an input, no? If not, how is this distinction shown to
users? How will it be clear to users when they can do one or the other?
Ojan
On Thu, Apr 1, 2010 at 3:53 PM, John Gregg john...@google.com wrote:
? Currently if I
drag multiple files onto an input that doesn't have 'multiple', I get only
the first one. (In Chrome.)
Some good default text from the UA, like Choose folder... instead of
Choose file..., would go far to solve that, I think.
-John
On Tue, Apr 6, 2010 at 12:38 PM, Ojan Vafai o
On Fri, Apr 23, 2010 at 8:41 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 23 Apr 2010 07:11:08 +0900, Ojan Vafai o...@chromium.org wrote:
But there is already a default UI that lets you select a folder, a file or
both (drag-drop). I don't see why this forces the UA to do anything
In addition to selection and scroll issues, needing to replace the entire
textarea value doesn't scale and thus limits what sorts of things you can do
with textareas. A general way to set a sub-part of a textarea's value seems
useful to me. I don't think we should tie that to setting the selected
On Wed, May 12, 2010 at 4:39 AM, Anne van Kesteren ann...@opera.com wrote:
On Sat, 24 Apr 2010 17:58:10 +0200, Ojan Vafai o...@chromium.org wrote:
My point is more that input elements currently support dropping files onto
them in multiple browsers. It's confusing for multiple that dropping
On Wed, May 12, 2010 at 4:31 AM, Simon Pieters sim...@opera.com wrote:
establishing a WebSocket connection:
[[
Note: There is no limit to the number of established WebSocket connections
a user agent can have with a single remote host. Servers can refuse to
connect users with an excessive
On Fri, Apr 23, 2010 at 2:34 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Fri, Apr 23, 2010 at 6:52 PM, Simon Pieters sim...@opera.com wrote:
It seems Hixie has decided to go back to the WebKit behavior in the spec
for designMode.
is currently
in the DOM3 spec and input is in the HTML5 spec.
Ojan
On Tue, Mar 16, 2010 at 6:35 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Mar 3, 2010 at 6:44 PM, Boris Zbarsky bzbar...@mit.edu wrote:
So I have to ask... Why are events _before_ the edit needed?
If we add these, then you
http://www.whatwg.org/specs/web-apps/current-work/#dom-getselection
Gecko returns null for a display:none iframe, but returns an empty Selection
object for a visible iframe with no selection. As best I can tell, WebKit
and Opera return a selection in both cases. I don't feel strongly about
which
WebKit has added the input event to contentEditable nodes. That part of this
proposal seemed non-controversial. Do other browser vendors support changing
the description of this event to apply to contentEditable nodes as well?
Ojan
On Wed, Jun 16, 2010 at 5:33 PM, Ojan Vafai o...@chromium.org
On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote:
This would mean that there is no way for an author to use @srcdoc
*without* sandboxing. This appears to be a minority use-case in the
first place (as far as I can tell, it's pretty much just useful for
testing purposes), but the
On Fri, Nov 19, 2010 at 9:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
Most of the use cases for script access to the exact device pixel ratio
that I've heard boil down to interfere with the user's ability to zoom,
which is why I haven't been eager to make it easier.
To be clear,
I agree that something like this is a valuable addition. I'm not sure
selectionAnchor is ideal. I was thinking
selectionDirection=forward/backward. It's equivalent really, but that
just seems more intuitive to me.
On Wed, Jan 12, 2011 at 11:35 AM, Marijn Haverbeke mari...@gmail.comwrote:
Hi,
On Sun, Jan 16, 2011 at 2:44 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
If we just have a boolean, it's unambiguous: the properties are all
logically separate. We don't want to emulate the DOM selection API,
IMO -- it's ridiculously complex for minimal
Looks good to me. Using a string instead of a boolean is more
future-extensible should we need to add a new type and is more consistent
with other attributes.
Just to be clear, when you say before/after, you mean in document order
right? So, it's unaffected by rtl, right?
On Fri, Feb 4, 2011 at
FWIW, chromium is planning on experimenting with disallowing modal dialogs
during the beforeunload/unload events.
http://code.google.com/p/chromium/issues/detail?id=68780
On Tue, Mar 1, 2011 at 11:57 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Feb 28, 2011 at 4:49 PM, Peter Kasting
On Tue, Apr 19, 2011 at 10:33 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 12 Apr 2011, Lachlan Hunt wrote:
We are investigating registerProtocolHandler and have been discussing
the need for a blacklist of protocols to forbid.
[...]
We'd like to know if we've missed any important
On Mon, May 9, 2011 at 9:05 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, May 6, 2011 at 8:55 AM, Tim Down timd...@gmail.com wrote:
- There are two events that exist: select and selectstart
- In IE, the selectstart event fires whenever the user starts changing
the selection within any
On Tue, May 10, 2011 at 9:51 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, May 10, 2011 at 9:03 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, May 10, 2011 at 8:55 AM, Tim Down timd...@gmail.com wrote:
newSelectionRanges on its own wouldn't be as useful as possible, since
it tells you
IE's behavior is better than the current spec because it allows a page to
find the focused element even if the focused element is in a frame by
walking down the frame tree if the activeElement is a frame.
There is existing code that depends on this:
On Fri, May 13, 2011 at 12:26 PM, Aryeh Gregor simetrical+...@gmail.com
wrote:
On Fri, May 13, 2011 at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote:
Note that br and div affect UBA differently so we must consider what
bidirectional text users want as well.
For example, if we had div
against
DOM mutations but will degrade the performance with O(n) where n is the
number of newSelection objects on the other hand. Any opinions?
- Ryosuke
On Tue, May 10, 2011 at 9:57 AM, Ojan Vafai o...@chromium.org wrote:
On Tue, May 10, 2011 at 9:51 AM, Ryosuke Niwa rn...@webkit.org wrote
It's not clear to me what forward/backward should do, but left/right should
do the same thing as using the left/right arrow keys. What do those do in
vertical writing mode?
On Wed, Jun 15, 2011 at 4:13 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi all,
WebKit would like to support visual caret
On Thu, Jun 16, 2011 at 12:12 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/16/11 3:00 PM, Aryeh Gregor wrote:
Assuming we don't match WebKit/Opera here, though, does everyone agree
we should still place constraints on what selections can be generated
by *user* actions? E.g., if you
On Thu, Jun 16, 2011 at 12:09 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Jun 16, 2011 at 11:50 AM, Aryeh Gregor aryehgre...@gmail.com
wrote:
Assuming we don't match WebKit/Opera here, though, does everyone agree
we should still place constraints on what selections can be generated
by
It is certainly the case that some large subset of users use spaces to align
content, not to mention really care about things like two spaces after
periods, etc. One way or another, contentEditable needs to support this.
If we were starting with a clean slate, the editing behavior we want is
On Mon, Jun 20, 2011 at 5:33 PM, Alexey Proskuryakov a...@webkit.org wrote:
15.06.2011, в 16:13, Ryosuke Niwa написал(а):
Now, in horizontal writing modes, 'left' and 'right' are used to move
caret
in visual order (in the sense of bidirectional text) and 'forward' and
'backward' are used
On Mon, Jun 27, 2011 at 2:39 PM, Alexey Proskuryakov a...@webkit.org wrote:
27.06.2011, в 14:30, Ryosuke Niwa написал(а):
FYI, I also posted this question on public-html-ig...@w3.org, and I got
exactly one response from Koji, who was supportive of my proposal.
Given that, I'm inclined to
Do any browser vendors agree with this or have objections? Hixie, this seem
OK to you?
These additions seem safe, simple and enable sites giving users a better
experience.
On Wed, Apr 20, 2011 at 11:32 PM, James Kozianski k...@chromium.org wrote:
Hi,
I'd like to propose the following changes
Agree. This seems strictly superior. Just to bikeshed on the name a bit,
since this is hanging off the navigator object, the name should probably
mention something about protocols, protocolState()?
On Fri, Jul 1, 2011 at 2:25 PM, Michael Davidson m...@google.com wrote:
From my perspective on
On Fri, Jul 1, 2011 at 2:58 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 07/02/2011 12:25 AM, Michael Davidson wrote:
From my perspective on Gmail, I would prefer to know if the user hasn't
registered because they declined previously or haven't been asked. If
they've declined
All the arguments for registering handlers aside, it ought to be possible
for a website to provide some UI for deregistering. For example, many users
will expect to go into gmail's settings to stop having gmail handle email
links. Gmail's help section needing to give users instructions on each
On Thu, Jul 7, 2011 at 6:15 PM, James Robinson jam...@google.com wrote:
PROBLEM
It is not possible to accurately measure time intervals using existing web
platform APIs, or to specify times at a given interval from the current
time. Date.now() and DOM timestamps are inadequate for this
at 10:30 PM, Ojan Vafai o...@chromium.org wrote:
All the arguments for registering handlers aside, it ought to be possible
for a website to provide some UI for deregistering. For example, many
users
will expect to go into gmail's settings to stop having gmail handle email
links. Gmail's
On Fri, Sep 23, 2011 at 11:49 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote:
Reference -
http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-autofocus
Here there is mentioned that Queue a task that checks to see if the
element is
On Sat, Sep 24, 2011 at 12:45 AM, Kaustubh Atrawalkar kaust...@motorola.com
wrote:
On Sat, Sep 24, 2011 at 1:57 AM, Ojan Vafai o...@chromium.org wrote:
Kaustubh, it would help if you could see what the behaviors for
disabled/hidden inputs are in various browsers as well.
Checked
On Thu, Oct 13, 2011 at 6:43 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 14 Oct 2011 05:07:18 +0900, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Oct 11, 2011 at 1:02 PM, Ehsan Akhgari eh...@mozilla.com wrote:
This sounds reasonable. The content attribute should be made
On Thu, Oct 13, 2011 at 7:19 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Oct 13, 2011 at 7:06 PM, Ojan Vafai o...@chromium.org wrote:
When an element with an undoscope goes from editable to non-editable, does
it then get a fresh undo stack? When it goes from non-editable to editable
On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa rn...@webkit.org wrote:
The same is true for having apply and reapply. Jonas wanted to get rid of
reapply altogether and just have
void apply(in boolean isReapply)
In this
On Thu, Oct 27, 2011 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Oct 27, 2011 at 11:28 AM, Ojan Vafai o...@chromium.org wrote:
On Thu, Oct 27, 2011 at 10:48 AM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, Oct 26, 2011 at 2:39 PM, Ryosuke Niwa rn...@webkit.org wrote
On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor a...@aryeh.name wrote:
On Fri, Oct 28, 2011 at 12:59 PM, Ryosuke Niwa rn...@webkit.org wrote:
I don't want string because then I'd have to do:
if (mode == 'reapply')
instead of
if (isReapply)
and the former is much more verbose.
It's a
On Fri, Oct 28, 2011 at 1:23 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Oct 28, 2011 at 9:42 AM, Aryeh Gregor a...@aryeh.name wrote:
On Fri, Oct 28, 2011 at 12:07 PM, Mike Taylor
michaelaarontay...@gmail.com wrote:
I would prefer if it returned the DOMTokenList, to enable chaining
On Fri, Oct 28, 2011 at 2:03 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, Oct 28, 2011 at 4:55 PM, Ojan Vafai o...@chromium.org wrote:
I agree in general. Changing add/remove is definitely worth doing. In
the
case of toggle, WebKit already returns a boolean. Returning the
DOMTokenList
We keep running into the use case where the physical position matters for
the tab order. The problem with just setting tabIndex (or CSS3 tab-index)
is that it takes the thing out of the natural order.
This problem comes up in a lot of places (e.g. absolute positioning). It's
recently come up for
On Tue, Nov 8, 2011 at 1:39 PM, Eric Sh. shedok...@gmail.com wrote:
I don't understand where are you going with this, is it a proposal for a
tab index scope?
Yes.
And the bug you linked has already been resolved.
It was resolved WONTFIX, but the problem still exists that items in a
Coming to this discussion very late. Maybe this has already been resolved.
FormatBlock should be dumb. It should not try to think about what the
author's intended semantics are. It should work on all block elements and
should just do the simple changing of the block from whatever type it
On Tue, Jan 10, 2012 at 2:38 PM, Adam Barth w...@adambarth.com wrote:
On Tue, Jan 10, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 14 Jun 2011, Adam Barth wrote:
On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org
wrote:
28.02.2011, в 21:38, Ojan Vafai
On Thu, Jan 12, 2012 at 6:22 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/12/12 5:16 AM, Simon Pieters wrote:
Note that it
removes the root element when the script element is executed, not at
DOMContentLoaded.
Ah, I missed that. I guess the HTML5 parsing algorithm means that now the
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#propertynodelist
DOM4 now has NodeList inherit from Array (see
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-nodelist).
As such, the getValues function is no longer useful. PropertyNodeList
= function() {
return this.map(function(node) {
return node.itemValue;
});
};
If this is commonly used then it might make sense to keep it so that
not every application has to duplicate this code.
erik
On Fri, Mar 30, 2012 at 14:21, Ojan Vafai o...@chromium.org wrote:
http
1. We should add iframe[seamless] { display:block; }.
http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2 already
expects iframe:not([seamless]) { border: 2px inset; }. In 90% percent of
uses, seamless iframes will not want a border and will want to fill their
container. This
On Wed, Apr 4, 2012 at 6:52 PM, Ojan Vafai o...@chromium.org wrote:
1. We should add iframe[seamless] { display:block; }.
http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2 already
expects iframe:not([seamless]) { border: 2px inset; }. In 90% percent of
uses, seamless
On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson i...@hixie.ch wrote:
Fullscreen then defines that when you make an element fullscreen, it's
pushed onto the top layer, and when an element is unfullscreened, it's
yanked from the top layer. The user emergency escape UI yanks all
fullscreened
We should add a crossorigin property on iframe that causes the request to
use CORS. If it's an allowed cross-domain request, then the page should
have access to the DOM of the frame.
Also, seamless should work (assuming the CORS request succeeded of
course). One tricky thing here is that seamless
We should add a keepalive attribute to iframes that prevents iframes from
being unloaded/reloaded when removed from or appended to a document.
Similarly, a disconnected iframe with keepalive should load. If the
keepalive attribute is removed from a disconnected iframe, then it should
unload.
I'm
this feature from WebKit because it
caused many security and stability problems. It turns out that
there's a lot of code in browsers that can't cope with a disconnected
iframe being alive.
Adam
On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote:
We should add a keepalive
On Thu, Apr 12, 2012 at 1:07 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/12/12 3:49 PM, Adam Barth wrote:
The seamless part might be workable, since that leaks information only
from the document in question. It's possible that there's a better
mechanism than CORS for a child frame to opt
On Thu, Apr 12, 2012 at 1:32 PM, Adam Barth w...@adambarth.com wrote:
On Thu, Apr 12, 2012 at 1:17 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, Apr 12, 2012 at 1:07 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/12/12 3:49 PM, Adam Barth wrote:
The seamless part might be workable, since
functionality into iframes and not
even be able to move them around in the DOM. It's OK to me, at least in the
short term, if we disallow keepalive for cross-document moves given the
problems WebKit had.
Adam
On Thu, Apr 12, 2012 at 12:41 PM, Ojan Vafai o...@chromium.org wrote:
I thought
as we unload when moving between documents, we should be pretty
safe as far as the issues which plagued magic iframe are concerned.
-Darin
On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote:
We should add a keepalive attribute to iframes that prevents iframes from
being
On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 29, 2012, at 1:41 PM, David Young dyo...@pobox.com wrote:
On Sun, Apr 29, 2012 at 10:38:26AM +0300, Aryeh Gregor wrote:
On Sun, Apr 29, 2012 at 10:29 AM, Ryosuke Niwa rn...@webkit.org
wrote:
That sounds like
On Fri, Apr 27, 2012 at 9:01 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 10 May 2010, Ojan Vafai wrote:
In addition to selection and scroll issues, needing to replace the
entire textarea value doesn't scale and thus limits what sorts of things
you can do with textareas. A general way
On Mon, Apr 30, 2012 at 11:01 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 30 Apr 2012, Ojan Vafai wrote:
On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak m...@apple.com
wrote:
Aryeh is referring to the DOM Range interface, which can only apply to
nodes that are directly in the DOM
On Wed, May 2, 2012 at 3:02 AM, Aryeh Gregor a...@aryeh.name wrote:
On Wed, May 2, 2012 at 9:59 AM, Ryosuke Niwa rn...@webkit.org wrote:
Great. I think the tricky part will be defining exactly how and when the
placeholder is displayed.
e.g. Should it be treated as if there is a text node
On Wed, May 2, 2012 at 10:08 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, May 2, 2012 at 10:06 AM, Ojan Vafai o...@chromium.org wrote:
I'm OK with having when the placeholder is displayed be up to the UA. I
can see that being platform specific.
But, we should spec when content
Proposed WebKit patch https://bugs.webkit.org/show_bug.cgi?id=87154. We'd
really like to hear if Hixie and/or other browser vendors have reservations
on making this change, otherwise, we'll commit this soon.
On Tue, May 22, 2012 at 10:41 AM, Nico Weber tha...@chromium.org wrote:
Hi,
The files
On Tue, May 22, 2012 at 6:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, May 22, 2012 at 10:41 AM, Nico Weber tha...@chromium.org wrote:
Hi,
The files attribute of the input element is currently marked readonly
[1], to protect from `myInput.files = /etc/passwd; myForm.submit()`.
On Wed, May 23, 2012 at 7:11 PM, Nico Weber tha...@chromium.org wrote:
On Wed, May 23, 2012 at 7:01 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, May 22, 2012 at 6:38 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't think simply marking the attribute as writable is the correct
solution
On Fri, May 25, 2012 at 10:03 AM, Boris Zbarsky bzbar...@mit.edu wrote:
The list is at http://www.whatwg.org/specs/**web-apps/current-work/**
I'd like to see us add event propagation into the parent document for
seamless iframes, e.g. key and mouse events inside a seamless iframe should
be refired on the iframe element.
Use-case 1: A global key event handler for keyboard shortcuts. Without
propagating the events, you need to add a key
On Wed, Jul 11, 2012 at 3:38 AM, Chaals McCathieNevile w...@chaals.comwrote:
On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai o...@chromium.org wrote:
Use-case 1: A global key event handler for keyboard shortcuts. Without
propagating the events, you need to add a key handler to each seamless
boundary. The only addition on top of that is that we need to
convert the coordinate space of mouse events appropriately when we cross
the boundary.
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting
Ojan
On Mon, Jul 9, 2012 at 4:26 PM, Ojan Vafai o
On Mon, Jul 16, 2012 at 9:24 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
On Sat, Jul 14, 2012 at 4:45 AM, Olli Pettay olli.pet...@helsinki.fi
wrote:
On 07/14/2012 12:38 AM, Ojan Vafai wrote:
It's been pointed out to me that what I'm asking for is essentially the
same retargeting
On Tue, Jul 17, 2012 at 7:51 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
An interesting quirk here is whether the full list of event ancestors
should be computed ahead of time (per
http://www.w3.org/TR/dom/#dispatching-events). If yes, then it's still
just like retargeting, but with
I made a proposal for this at the end of
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/036584.html.
The best way to get this specced is to provide additional use-cases (for
having intrinsic sizing without inheriting style) in addition to use case
#3 in my email.
On Wed, Aug 29, 2012 at 4:27 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 17 Jun 2012, Aryeh Gregor wrote:
On Thu, Jun 14, 2012 at 1:11 AM, Ian Hickson i...@hixie.ch wrote:
I strongly disagree. input and textarea are high-level constructs,
so it's fine for them to be defined by the UA's
On Wed, Sep 5, 2012 at 1:47 PM, Ian Hickson i...@hixie.ch wrote:
For HTMLOptionsElement, the situation is more murky.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1739
From what I can tell, IE doesn't do direct named access, you have to do it
via item() or namedItem(). The
On Thu, Sep 6, 2012 at 3:56 AM, Aryeh Gregor a...@aryeh.name wrote:
On Sat, Sep 1, 2012 at 4:22 AM, David Young dyo...@pobox.com wrote:
This demonstrates some unexpected contenteditable results on
Chrome 21.0.1180.82 under Mac OS X. I cannot seem to return the
contenteditable to the empty
On Tue, Sep 11, 2012 at 1:57 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 11 Sep 2012 10:29:06 +0200, Elliott Sprehn espr...@gmail.com
wrote:
On Tue, Sep 11, 2012 at 1:23 AM, Simon Pieters sim...@opera.com wrote:
...
The title element is required in HTML. What are the use cases for
On Tue, Sep 11, 2012 at 10:20 AM, Anne van Kesteren ann...@annevk.nlwrote:
On Tue, Sep 11, 2012 at 7:07 PM, Ojan Vafai o...@chromium.org wrote:
Is it? All I see in the spec is There must be no more than one title
element per document.
http://www.whatwg.org/specs/web-apps/current-work
1 - 100 of 120 matches
Mail list logo
