Ian Hickson wrote:
I'm all for handling it in one place. What precisely do you want the
behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- the first
svg:title element may come after the firsthtml:title element, and
vice versa. Also consider when one or the other is primary but the
Jonas Sicking wrote:
An even simpler solution would be to say we choose the first
html:title orsvg:title in document order. That has the nice
property that we align SVG and HTML more.
Although as Dirk pointed out, SVG distinguishes title elements that
are children of the root element vs
Cameron McCormack wrote:
Document.activeElement is currently defined to return the body
element if there is no element with focus, or null if there's no
body element. I think it needs to return the root element when
the document isn't an HTML document (like an SVG document).
Anne van Kesteren
Document.activeElement is currently defined to return the body element
if there is not element with focus, or null if there's no body
element. I think it needs to return the root element when the document
isn't an HTML document (like an SVG document).
Currently, HTML defines Document.title on SVG documents to defer to
whatever the SVG specification defines for SVGDocument.title. The
SVGDocument interface has gone away, so this will need to be updated.
From some basic testing, it looks like SVG needs the same behaviour as
HTML -- first
On 1/02/2014 9:01 pm, Cameron McCormack wrote:
Do you want to just handle that all in HTML? I'm not sure there's much
value to duplicating either the searching for the title element or the
white space collapsing behaviour in SVG itself.
Oh, and for the setter, it looks like implementations
On 1/02/2014 10:01 pm, Dirk Schulze wrote:
Could you be more specific about that? It is not just the first title
element in the document, but the first direct child of the element
root.
That is what the spec says but that is not what implementations do.
A title nested in a group or
On 22/01/2014 3:09 pm, Boris Zbarsky wrote:
Or neither, if desired. In Gecko we don't expose the SVG* properties in
IDL at all...
We decided against requesting adding an onzoom attribute to
GlobalEventHandlers to avoid any complications with whatever solution
comes out of the CSSWG who are
Tingan Ho wrote:
Wouldn't it be good to specify the behavior of type null in *append* method
of Form data?
Right now Safari sends string* null.* Chrome sends empty string . I
think Chrome's implementation is more right, because in a html form you
can't send null value, just empty strings
Hi Victor,
Victor Costan wrote:
I'm trying to re-implement Range.createContextualFragment in Blink
following this whatwg spec:
http://domparsing.spec.whatwg.org/#extensions-to-the-range-interface
There are two issues I'd like to discuss, related to the use of
createContextualFragment in SVG
Cameron McCormack wrote:
OK. I propose then that we allow [Unforgeable] on the interface, which
means:
* attributes get own, non-configurable accessor properties (with setters
if they are not readonly attributes), and no property on the prototype
* operations get own, non-configurable, non
Dirk Schulze wrote:
We can not eliminate SVGDocument until you want to have SVG specific
attributes on Document ;). This was not the discussion on the SVG
WG. But we do want to share all methods with HTMLDocument where is
makes sense, which are most of them. HTMLDocument, as noted by Boris,
As part of aligning SVG with some not-so-HTML-specific features of HTML,
the SVG WG would like to support data-* attributes on SVG elements. In
mixed HTML/SVG documents, it seems like you would want to be able to use
these attributes regardless of whether the elements are HTML or SVG, or
On 30/01/13 6:28 PM, Ian Hickson wrote:
That's weird. heycam, can you elaborate on this? The addHitRegion() case
in particular never makes sense to be called without a dictionary
containing at least one member. Do we have to allow it?
This is to encourage (require, really) API design that
On 16/12/12 9:34 PM, David Bruant wrote:
WebIDL needs to embed in some way the notion of origin to enable
throwing for security reasons in the right places.
One idea would be to add an [OriginAware] extended attribute:
* On operations (like in Boris case), an origin check would be performed
On 8/01/13 7:31 AM, Ian Hickson wrote:
heycam, did we resolve this at the WebIDL level by any chance? Or is this
still open? (If the latter, is there a bug# for it? Or is this an HTML
problem I need to fix myself?)
No, this didn't get resolved.
I'm wondering if anybody has had any further thoughts on how summary
and details should be made stylable.
My initial feelings were along the lines of Tab's -- the disclosure
widget feels very much like something that is created like a list bullet
and matched with ::marker. But reading Ian's
On 22/12/12 10:06 PM, Anne van Kesteren wrote:
Is there not some way we can have a lineDash attribute that returns a
manipulatable object that inherits from Array rather than the current
Java-like API? I remember this was discussed when getLineDash() and
setLineDash() were added, but I think
On 23/12/12 12:40 AM, Anne van Kesteren wrote:
I guess dashList is somewhat simpler, but I think it would be nice if
it still did type coercion.
In that case, I guess we are reliant on whatever ES-allowed Array
extending is possible, and I haven't followed that for a bit. Is this
actually
On 23/12/12 1:01 AM, Tobie Langel wrote:
Array-like objects which don't inherit from the Array object and are
thus missing methods one would expect to find on them (forEach, join,
etc.) is one of the biggest WTF of the Web platform. We should be doing
whatever it takes to fix this.
I agree
On 16/12/12 2:05 PM, Boris Zbarsky wrote:
There's no way to express that in WebIDL, but I think that's a bug we
should fix in WebIDL. We should allow getters and setters for
attributes to accept different IDL types...
Yeah, that has come up a couple of times now. Filed
On 4/12/12 6:31 AM, Boris Zbarsky wrote:
It's a similar situation, yes. But in this case I don't see why you'd
need an IDL annotation of any sort at all. If you want the behavior to
be the same, just don't define onscroll on Bar at all and define the one
on Foo to special case the two Foo
On 4/12/12 11:33 AM, Ian Hickson wrote:
Per our IRC discussion just now, I think I would propose that when a
method/setter/getter from a prototype of interface A is called against an
object that is of an interface B (or one of B's descendants), where B is a
subclass of A, and B defines its own
On 4/12/12 12:11 PM, Boris Zbarsky wrote:
Hmm. That, as phrased, is pretty complicated to implement in a
performant way, if the two methods/getters/setters have the same
signatures...
Since I'm not terribly familiar with our generated bindings code, I'm
not really sure what that would be.
Boris Zbarsky:
I guess from my point of view, extending the existing member
[Unforgeable] to a wider class of members without changing anything else
about it seems simpler than having two separate meanings to
[Unforgeable] depending on what it's decorating... But maybe we're
thinking about
Boris Zbarsky:
So we have indications that making everything on this
interface unforgeable is sufficiently web-compatible.
OK. I propose then that we allow [Unforgeable] on the interface, which
means:
* attributes get own, non-configurable accessor properties (with setters
if they are not
Boris Zbarsky:
I can live with this, but why is this better than just allowing
[Unforgeable] on all operations and attributes and defining an object
valueOf(); /* returns self */ on Location?
If we really do want to make all Location interface members be
unforgeable, then moving the
Boris Zbarsky:
I guess the question is whether we're more likely to need [Unforgeable]
on some other entire interface or whether were more likely to need
[Unforgeable] on a single member that's not a readonly attribute. Of
course we might never need either one...
I'm inclined to simplify now
Tobie Langel:
No. It sounds like I should be fast asleep instead of making a fool of
myself and wasting everybody's time.
It is however the kind of thing that Tab wants to do for CSS (have a
window.CSS object that is like a namespace object for some CSS
interfaces -- the concept for which
Rik Cabanier:
There was a discussion in the SVG WG about dropping the
SVGAnimatedxxx objects and have replace them with regular values. We
would need some tricks so we can change the DOM, but make it
backward compatible at the same time.
We have discussed this a few times, and I would
Rik Cabanier:
Who would do this in the current SVG world? As you say, (!elt.className)
would always return false...
Are you worried that new content won't work with an old viewer?
No that would actually continue to behave the same. So I misspoke when
I said things will break -- author
Daniel Cheng:
We've reverted it back to an Array in WebKit.
Should the live requirement remain if it's an Array rather than a
DOMStringList?
I would think so. Note that if the spec is changed to
readonly attribute DOMString[] types;
it means that the object returned from that property is
Cameron McCormack:
The two Location objects stringify to the same thing, but are not ==. I think
this can be confusing.
Ian Hickson:
Can we overload equality for objects?
No, not within the confines of ECMAScript.
This problem of using bare variables names rather than
window.variableName in event handler attributes (which Boris mentions in
https://developer.mozilla.org/Writing_Forward_Compatible_Websites) seems
annoying. Is there any way we can avoid it by codifying current
property lookup behaviour
On 18/11/11 8:21 AM, Adam Barth wrote:
Another option is to tokenize the elements as usual, but put them into
a new document created for thetemplate element (presumably using
the usual tree-building rules). Because this document won't have a
browsing context, all the elements would be inert,
On 2/08/11 6:29 AM, Tab Atkins Jr. wrote:
It's a confusion shared by all objects, though:
var x = [1,2];
var y = [1,2];
alert([x,y,x==y).join(' ');
This alerts 1,2 1,2 false.
That is true, but I get the impression that some authors don't know that
the Location object is actually an object
Jumping in the middle of this thread to pick up on one aspect...
On 28/07/11 6:15 PM, Ian Hickson wrote:
Are we really concerned about objects stringifying to [Object Foo]?
It seems that the usefulness of such stringification is far outweighed by
the usefulness of being able to treat the
On 28/07/11 6:59 PM, Boris Zbarsky wrote:
Why, exactly? I thought for SVG the evt thing was only relevant for
content attributes, not IDL attributes.
That's right. (Maybe Anne meant the Function used internally for the
content attribute?)
Per-Erik Brodin:
Maybe the null-check in step 3 under When the PeerConnection()
constructor is invoked .. should not be there anymore since
signalingCallback is not nullable.
Yes, that step’s not necessary any more.
--
Cameron McCormack ≝ http://mcc.id.au/
://www.w3.org/Bugs/Public/show_bug.cgi?id=10640
--
Cameron McCormack ≝ http://mcc.id.au/
, and I’ll be looking at improving
this in Web IDL soon.
--
Cameron McCormack ≝ http://mcc.id.au/
. The current behaviour is
confusing.
--
Cameron McCormack ≝ http://mcc.id.au/
() and MessagePort.postMessage() these
would need to be sequence or array types so that you could pass in a JS
Array object.
--
Cameron McCormack ≝ http://mcc.id.au/
behaviour.
If people have opinions on whether all JS Number → IDL integer type
conversions should clamp or wrap, or whether Web IDL should just have an
annotation to indicate what kind of conversion is used, please comment
in the bug.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
checks are done purely at
the UI level, and information about the dictionary is not exposed to
script.
--
Cameron McCormack ≝ http://mcc.id.au/
lives on Element.
Would classList provide access to the SVG element’s base or animated
value of class=? Base probably makes more sense.
--
Cameron McCormack ≝ http://mcc.id.au/
.
What about “attitude”?
--
Cameron McCormack ≝ http://mcc.id.au/
few’
case).
OTOH, passing in undefined explicitly as the second argument would have
it converted to the string undefined.
--
Cameron McCormack ≝ http://mcc.id.au/
duplicate definition. Manu’s Makefile will need to split out the
HTML 5 specific parts (between the !--START html5-- and !--END
html5-- markers). The ‘source-html5 : source’ rule in
http://dev.w3.org/html5/spec-template/Makefile will handle that.
--
Cameron McCormack ≝ http://mcc.id.au/
was lifted from that and put in SVG Tiny 1.2:
http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioElement
which says:
This specification does not mandate support for any particular audio
format.
--
Cameron McCormack ≝ http://mcc.id.au/
.
window.sessionStorage.removeItem;
// This calls
// window.sessionStorage.removeItem.[[Delete]](removeItem), which
// invokes the name deleter behaviour because removeItem is the name
// of a corresponding named property.
delete window.sessionStorage.removeItem;
--
Cameron McCormack ≝ http
Cameron McCormack:
Another edge case:
…
// Just a normal property deletion...
delete Storage.prototype.removeItem;
Actually I just realised that this won’t work, since properties that
correspond to operations are DontDelete. But this and the other example
can still demonstrate when
/xptr-framework/
--
Cameron McCormack ≝ http://mcc.id.au/
for other languages.
--
Cameron McCormack ≝ http://mcc.id.au/
nowhere near complete, though
you can see that there are some operations arguments and attributes that
stringify null to null (“S” in the column).
--
Cameron McCormack ≝ http://mcc.id.au/
counterintuitive default behaviour of
converting a valid value of the type to a different value of that type?
--
Cameron McCormack ≝ http://mcc.id.au/
rejig the tests to get that information.
Cameron McCormack:
OK. So what is more important for choosing the default: fewer
exceptions (and thus fewer [Null=…] things polluting the IDL),
consistency with the default stringification behaviour of ECMAScript,
or avoiding the somewhat
that will be needed.
--
Cameron McCormack ≝ http://mcc.id.au/
with [Variadic],
the two operations could just be combined into one:
interface Window {
…
any showModalDialog(in DOMString url, [Variadic] in any arguments);
…
};
--
Cameron McCormack ≝ http://mcc.id.au/
The applicationCache attribute on the Window interface seems to be
missing.
--
Cameron McCormack ≝ http://mcc.id.au/
instead, or 0 if there is no default value.
Similar wording would be needed for other paragraphs in this section.
--
Cameron McCormack ≝ http://mcc.id.au/
Continuing a conversation from IRC
(http://krijnhoetmer.nl/irc-logs/whatwg/20081217#l-187):
Cameron McCormack:
heycam Hixie, i think it would be better if DOMStringMap still
had operations annotated with [NameGetter] etc., and then for me to
introduce something in Web IDL to indicate
a document that is both
valid HTML 4 and HTML 5, since they both require a different DOCTYPE to
be used.
--
Cameron McCormack ≝ http://mcc.id.au/
Robert O'Callahan:
Why not just open new window and move the playing audio element from the
old window into the new window? You might need to call play() on it again in
the new window, but you shouldn't lose your place in the stream.
Why shouldn’t that throw a WRONG_DOCUMENT_ERR?
--
Cameron
of thing.
--
Cameron McCormack ≝ http://mcc.id.au/
guide to
do that sort of thing.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
family of
operations quite nicely.
They’re sensible names. I’ll append() that on my TODO list.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
; ns = ns.nextSibling)
if(ns.nodeType == 1)
return ns;
return null;
};
There is http://www.w3.org/TR/ElementTraversal/, which specifies just
this.
--
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL
.
--
Cameron McCormack, http://mcc.id.au/
xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED]
69 matches
Mail list logo
