>
Re: [whatwg] Remove addCueRange/removeCueRanges
On Sat, 15 Aug 2009 08:47:32 +0200, Jonas Sicking wrote: > The problem is that you can't use fragment identifiers with data-URIs. > > For example > > data:text/plain,hello world#frag > > Represents a text/plain document with the contents: > > hello world#frag > > It does not represent the 'frag' part of a document with the text 'hello > world'. Actually, I think that is false (and a bug in Firefox). At the time the data URI RFC was written RFC 2396 was still the URI RFC and there fragment identifiers were not a formal part of the URI syntax but rather something you could append to any URI during retrieval operations, which is clearly what data URIs are for. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Remove addCueRange/removeCueRanges
On Fri, Aug 14, 2009 at 4:08 AM, Philip Jägenstedt wrote: > On Fri, 14 Aug 2009 12:48:59 +0200, Silvia Pfeiffer > wrote: > >> On Fri, Aug 14, 2009 at 7:54 PM, Dr. Markus Walther >> wrote: >>> >>> >>> Silvia Pfeiffer wrote: 2009/8/14 Dr. Markus Walther : > > Hi, > >> The .start/.end properties were dropped in favor of media fragments, >> which the Media Fragments Working Group is producing a spec for. > > Who decided this? Has this decision been made public on this list? > >> It will >> be something like http://www.example.com/movie.mov#t=12.33,21.16 > > var audioObject = new Audio(); > audioObject.src > > ='data:audio/x-wav;base64,UklGRiIAAABXQVZFZm10IBABAAEAIlYAAESsAAACABAAZGF0Yf7///8A'; > // play entire audio > audioObject.play(); > // play (0.54328,0.72636) media fragment > ? Not in this way. In fact, the new way will be much much simpler and does not require javascript. >>> >>> With the code snippet given I was pointing out that it is not obvious >>> (to me at least) how the proposed media fragment solution covers data >>> URIs. If it is not meant to cover them, it is limited in a way that the >>> solution it seeks to replace is not. >> >> I see no reason why they should not be applicable to data URIs when it >> is obvious that the data URI is a media file. This has not yet been >> discussed, but would be an obvious use case. >> >> BTW: Did the start and end attribute implementations that you refer to >> cover the "data" scheme, too? > > To my knowledge/experience, there is nothing special about data URIs. Any > differences in how they work with the DOM interface or media fragments are > more than likely implementation bugs. The problem is that you can't use fragment identifiers with data-URIs. For example data:text/plain,hello world#frag Represents a text/plain document with the contents: hello world#frag It does not represent the 'frag' part of a document with the text 'hello world'. / Jonas
Re: [whatwg] .tags on HTMLCollections
On Fri, Aug 14, 2009 at 12:02 PM, Jonas Sicking wrote:
> On Fri, Aug 14, 2009 at 3:35 AM, Ian Hickson wrote:
>> On Fri, 7 Aug 2009, Jonas Sicking wrote:
>>> >
>>> > I haven't removed HTMLCollection.tags yet, since it appears to be
>>> > implemented by most browsers. If we can get Opera and WebKit to remove
>>> > support, then I'll remove it from the spec.
>>>
>>> Given that we have some data indicating that .tags() is not needed for
>>> web compatibility (Firefox doesn't support it and has received no
>>> requests for it, or bugs indicating sites needing it), and so far only
>>> weak data indicating it is needed (UAs support it, but not clear why),
>>> why not leave it out of the spec for now?
>>>
>>> UAs are always free to continue supporting it if they so please.
>>>
>>> I have very little desire to add support for anything to gecko "just in
>>> case", without any data indicating anyone would use it, much less needs
>>> it.
>>
>> HTMLCollection.tags is specified for the same reason is -- a
>> majority of browsers support it. I'd like to remove it, though. I
>> encourage you to convince other browser vendors to drop support for this
>> feature.
>
> The difference is two-fold. First of all I thought we had indication
> that sites actually relied on , i.e. we have some sort of data
> on that it's actually a used feature. Is that not the case?
>
> Second, .tags() arguably better belongs in a DOM-Core spec. So we
> could remove it for the same reason that HTML doesn't specify CSS
> quirks-mode behavior, that it's something better left to other specs.
The DOM core has getElementsByTagName. Kind of a long name, but the
behavior is standard and though buggy in IE <= 8, is more consistent.
What exactly does .tags return? NodeList, StaticNodeList, TagsArray?
What about .tags("*")?
> Why doesn't HTML for example define Element.children? That is also
> supported by a majority of other browsers (the exact same set of
> browsers even).
Implementing "children" would be a mistake. This was discussed on
comp.lang.javascript. Recently, in fact:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/18beac3cd1e06c29
To save the trouble of reading that thread, MSIE's "children" returns
a list of "DHTML Objects". Those objects include comment nodes. The
test case in the linked thread shows that.
Juriy followed up to post about Divergent behavior in Safari 2 and
Richard mentioned divergent behavior in IceBrowser, and the example I
posted demonstrates (with explanation) the problem with children and
getElementsByTagName in IE <= IE8. Any code that wanted to use
".children" would need to do more feature testing than it would be
worth.
If a feature is to be created to get child Elements, it should have a
new name. AISB, "childElements", in Jan 2008,
| REally, all I want is
| nextSiblingElement/previousSiblingElement/childElements properties so I
| don't have to have library code or write a for() loop every time i want
| to just find the next sibling element.
I disagree with the decision to not include those properties.
>
> In general, I suspect if the only criteria to having something in the
> spec was "supported by a majority of browsers and not currently
> defined by any other spec", then I strongly suspect the spec is
> missing a lot of features.
>
Can you explain the "Global Scope Polluter"? :-D
http://groups.google.com/group/comp.lang.javascript/msg/c46682d862939173
AYCS from that thread, we didn't quite figure out how the Global Scope
Polluter works. Would be helpful to have the author or sr for that
code, or anyone who understands it and has the time jump in on that
and explain a little more.
This "Global Scope Polluter" is an MSIE "lets make it easy" feature,
sort of like callable collections. In retrospect, it seems to have
caused more harm than good.
Garrett
Re: [whatwg] Typo in 1.9 - "attributed"
On Mon, 10 Aug 2009, Chris Cressman wrote: > > >From section 1.9: > > "Each element in the DOM tree is represented by an object, and these > objects have APIs so that they can be manipulated. For instance, a > link (e.g. the a element in the tree above) can have its "href" > attributed changed in several ways:" > > _attributed_ instead of _attribute_ Thanks, fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Redirects and draft-hixie-thewebsocketprotocol
On Fri, Aug 14, 2009 at 4:06 PM, Ian Hickson wrote: > > On Sun, 9 Aug 2009, Jeremy Orlow wrote: > > > > I feel like redirects add unnecessary complexity. > > > > We're already asking application developers to handle ACKing, keep > > alives, multi-plexing, connection limiting, authentication, etc > > themselves. To me, it doesn't seem like much of an additional burden to > > ask them to handle redirects. And by keeping the spec simple, I think > > we'll increase the chances of quick adoption by UAs, which will speed up > > the adoption by web apps, which will give us feedback on what features > > web developers actually want much quicker. > > The use case for redirects is if Google (say) provides a WebSocket service > that lots of sites around the Web uses, and then Google wants to move the > service to another host, without transparent redirects, all the pages > using the service will break until they can be updated, whereas with > redirects, we can just redirect and be done with it. Or the protocol Google (or anyone else) creates to transport the data can support this. If an application has to deal with ACKs, it's only a small jump to insist it also handles the initial negotiation (authentication, redirects, etc) itself. This is why I think it's better to not have anything at all rather than have something that's half-baked. I whole-heartedly agree that these features should be in v2.
Re: [whatwg] Minor presentational issue in draft-hixie-thewebsocketprotocol
On Sat, 8 Aug 2009, Adam Barth wrote:
>
> [[
> Send the string "WebSocket-Origin" followed by a U+003A COLON (":")
> followed by the ASCII serialization of the origin from which the
> server is willing to accept connections, followed by a CRLF pair
> (0x0d 0x0a).
>
>For instance:
>
> WebSocket-Origin: http://example.com
> ]]
>
> The prose above is missing the space after the ":" that is present in
> the example. The next chunk of text, for WebSocket-Location, has the
> same issue.
Fixed, thanks.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Redirects and draft-hixie-thewebsocketprotocol
On Sat, 8 Aug 2009, Adam Barth wrote: > > In fact, the situation is worse than the above because the websocket > protocol supports cookies. Instead of relying on a firewall and IP > authentication, the victim server could be on the public Internet and be > relying upon cookie authentication. > > I think there are a number of ways of resolving this issue: > > 1) We could use Sec-From instead of Origin because Sec-From implicates > the full redirect chain instead of just the origin that initiated the > request. On IRC, Ian said he doesn't like this choice because servers > might not validate this header properly. My concern here is that to confirm the server is checking Sec-From we'd want the server to include some sort of response, and I'm not really sure what that would be. Maybe just WebSocket-Sec-From: ..., where it contains the same value as Sec-From, but Sec-From only gets included on redirects? > 2) Instead of handling the redirect inside the websocket protocol, we > can report the redirect back to the web site making the request (in this > case example.com). Then the trustworthy web site would then have the > option of following or not following the redirect. If we did this, we > would have to ensure that the redirecting server understands the > websocket protocol (probably by requiring it to send WebSocket-Origin or > some such) to avoid leaking the targets of already-existing redirects. > Also, it's unclear on what basis the web site would decide whether to > follow the redirect. > > 3) We could restrict redirects to the same origin. This has the > disadvantage of not covering the full use case of redirects. > > 4) We could remove support for redirects. On Sun, 9 Aug 2009, Jeremy Orlow wrote: > > I feel like redirects add unnecessary complexity. > > We're already asking application developers to handle ACKing, keep > alives, multi-plexing, connection limiting, authentication, etc > themselves. To me, it doesn't seem like much of an additional burden to > ask them to handle redirects. And by keeping the spec simple, I think > we'll increase the chances of quick adoption by UAs, which will speed up > the adoption by web apps, which will give us feedback on what features > web developers actually want much quicker. The use case for redirects is if Google (say) provides a WebSocket service that lots of sites around the Web uses, and then Google wants to move the service to another host, without transparent redirects, all the pages using the service will break until they can be updated, whereas with redirects, we can just redirect and be done with it. I've removed redirect support for now, but I think we should have support for it at some point. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 Script Tag
On Fri, Aug 14, 2009 at 11:48 AM, Cready, James wrote: > Except of course for the following: >and > > And these "obsolete elements" still supported by legacy UAs: > and Those are just unclosed, they're not self-closing. If you use the "/>" syntax it's not closing the tag, it's just ignored. If this proposal were accepted, would become the only tag in text/html where "" is treated any differently from " ". > == ==