Re: [whatwg] Installed Apps

[Adam de Boor]

On Wed, 29 Jul 2009, Michael Kozakewich wrote:
>
> How many applications do we expect any one user to have open? I would
> imagine one would do fine on the Taskbar or in the Notification Area,
> like other programs, but a manager would be good if a user had a great
> deal of applications running at once.

Realistically speaking, users will soon have many applications open if we
make this available: Flickr, Mail, Calendar, Facebook, Reddit, Twitter,
BBC News, their Bank, Google Voice, ... I would expect hundreds of sites
to make use of such a feature.


I have to say, I get confused by statements like this. If there are hundreds
of sites that would find the feature useful, it sounds like a useful feature
to have, one that fits in better with the way application writers understand
to write applications. The perspectives I've heard in this thread basically
say that 5 years from now, applications should be written such that there's
a server in the browser, at which point I have to wonder why don't we go
back to getting all the markup from the server and injecting it into the
page?

a

Re: [whatwg] BWTP for WebSocket transfer protocol

[Maciej Stachowiak]

Hi Greg,

On Aug 7, 2009, at 10:07 PM, Greg Wilkins wrote:



Again this is valuable feedback.

That's three -0' or -1's on the look-a-like-HTTP approach.

I'll ponder what sort of simplifications could be made
if the HTTP style is dropped.


I'm not sure the HTTP-style framing is necessarily a minus, it's just  
not much of a plus. I think the complexity cost is from the number of  
features added. I think a possible fruitful approach might be:


- Review what features BWTP adds.
- Pare down to just the most essential ones that provide a lot of  
benefit at the protocol level relative to doing them at the  
application level.
- Leave enough extensibility that other useful protocol-level features  
can be added in a future version.


I'm concerned about the 1.0 version of the protocol, whatever it may  
be, being too complex. The downsides of complexity are: (a) longer  
time-to-market for the core functionality; (b) likely worse  
interoperability in the initial implementations; (c) more risk of  
security bugs. On the other hand, I would also be concerned about  
deploying something that didn't have an elegant path to future  
extension.


I intend to look over the protocol details and I will encourage the  
other folks doing implementation or design work on WebKit's WebSocket  
to give it a look. Then hopefully I can add a more concrete proposal.


I tentatively agree with Jonas that in-protocol multiplexing sounds  
like one of the most valuable additional features, as compared to  
WebSocket Protocol.


Regards,
Maciej

Re: [whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

Jonas,

taking some of your comments out of order

> My gut feeling on BWTP vs. websocket is that BWTP carries some
> unneccesary complexity/overhead by allowing arbitrary headers in each
> frame, whereas websocket is unnecessarily low level.

I added the headers to BWTP (headers), because I didn't like the
total lack of meta data in websocket.I then added virtual
connections afterwards.

But now you mention it, arbitrary headers in each frame is probably
excessive since it could be argued that all the messages to/from a
given URI are likely to have mostly same metadata so perhaps a protocol
that supports virtual connections does not need per message
meta data.  So maybe metadata per virtual connection meta-data is
sufficient?


> I don't think BWTP gains a lot by using HTTP-like syntax, as I don't
> think that in reality a lot of existing HTTP code can be reused.

I don't think HTTP-like syntax is essential.  I was just using
it to start from a familiar place.   It is the features that
BWTP has that Websocket lacks that I think are important
(plus I admit a total dislike of 0 delimited framing :).


> I agree that these are very interesting features. Especially
> connection multiplexing is something that I think is a good idea, for
> the reasons you've mentioned elsewhere in this thread (multiple
> widgets on the same page). But even compression is nice if it was
> possible.

Indeed it is the features that are more important ideas in BWTP
rather than the syntax of the protocol.

The features that I feel are important to have in the protocol
are:

  + mime encapsulated content types (not just utf-8 and binary).
  + extensible content-encoding and/or transfer encoding
  + multiplexing
  + orderly close

Nice to have features include:
  + message segmentation (good for flow when multiplexing).
  + intermediary participation
  + strict in what you generate, forgiving in what you parse
  + BNF style specification rather than algorithmic specification.
  + per message meta data


> My impression is like Maciejs, that we wouldn't be able to reuse much
> of our current HTTP infrastructure in order to implement BWTP. At
> first glance only the header-parsing code would carry over directly,
> but that's not many lines of code and so doesn't seem like a big win.

Again this is valuable feedback.

That's three -0' or -1's on the look-a-like-HTTP approach.

I'll ponder what sort of simplifications could be made
if the HTTP style is dropped.


cheers

Re: [whatwg] Installed Apps

[Michael Kozakewich]

From: "Jonas Sicking" 
Sent: Friday, August 07, 2009 5:07 PM

2009/7/30 Ian Fette :

That being said, I think there are valid use cases for out-of-band
notifications, for example for calendar events or "status update" type
applications such as Facebook or Twitter.

I'd like to explore whether we can accommodate this notification use 
case

without bringing the full power of the Web platform to bear, and thereby
opening up a lot of attack surface on the client. Here's one rough 
sketch of

an idea:

* Notification Feeds *

Often, web applications would like to give users the option to subscribe
to notifications that occur at specific times or in response to 
server-side

events, and for the user to get these UI notifications without a
prerequisite that the web app is open or that the browser is running. 
There
may be a desire to do client-side computation as well, but often just 
the
ability to give the user a notification solves the basic user 
interaction

problem.

One possible way to address this kind of use case is to let users
subscribe to a "feed" of notifications. This feed could use standard
syndication formats, such as RSS or Atom. But instead of being displayed 
in

a traditional feed reader, it's displayed in the form of transient
notifications (along the lines of Growl on Mac OS X) which are posted 
for
each new event. To allow some pre-scheduling of events, each item can 
have a
date and won't be displayed until that date - this way a calendar can 
give
you your feed of upcoming events and you can still get notifications 
when
offline. In the case of something like email or Twitter, obviously 
there's

no sensible way to get notifications when offline since they depend on
unpredeictable server-side activity. There could even be a client-side 
API
that lets a Web app schedule items on a subscribed notification feed 
from

script, to enable scheduling calendar events offline. Each notification
would have the option to unsubscribe from the notification feed, to 
reduce

spam potential.

Notice that this opens up a lot less attack surface. The user has to
actively opt in to subscribing to the notification feed, just as for an 
RSS
feed. This makes it much less likely they end up with a subscription to 
a
shady site. And the notifications are passive data items (probably no 
script

should be allowed in a notification, if the format is HTML and not just
plain text), so they open up a lot less security risk. Obviously this is
less powerful than the ability to run arbitrary code in the background. 
But

it could address a large chunk of the use cases with much less security
risk.


It addresses some use cases (calendar, perhaps), but I would still like 
to

be able to e.g. keep my email up to date. Do I need the "full power" /
"fully general" solution? I don't know, perhaps the push mechanism can be
structured in a way that it gets into my database or whatever storage
mechanism I am using for offline data storage?


For the purpose of notification, it seems we have the following solutions:
-Push message
-SMS
-RSS/Atom feed
-Polling (Probably through JavaScript)

Which will manifest in the following types of program:
-Hidden browser page, Standalone browser tab, Persistent worker, or the 
browser's main background process, as part of the browser
-Extraneous app or device (SMS to phone, or small-footprint desktop 
feed-reader)


Any others you can add to those lists?

(You can read the rest, or visit the summary near the bottom.)

To go through the methods:
RSS/Atom is usable at this very moment, as is JavaScript polling and SMS. 
SMS can be expensive, but Twitter has proven how useful it can be. I'm not 
sure what applications support push messages.


Deciding where the messages appear is the tricky part: A low-footprint, 
invisible feed-reader app can be run in the background and pop up messages 
when they're received. This will require users to install third-party tools, 
which could integrate themselves with the browsers to open links or manage 
'feeds'.

Phones could be used to handle SMS notifications or push messages.

The browsers could check for updates in a tab, but there are a couple things 
that need to change before this becomes feasible:
1) Browsers need to be able to pop up a notification in the corner, possibly 
with a link that sets focus to the notifying tab,
2) Browsers need to get the notifying tab out of the way, either by 
shrinking it to a notification area or by running it as a background process 
(where it can be accessed from the browser through some sort of Application 
Manager), and
3) Hidden tabs need to continue to run when the browser is closed (i.e. the 
browser's main process continues to run) until the hidden page is exited.


It sounds like the browser could have a small background process that 
manages notifications, and a webapp (such as Gmail) could register with the 
browser's notification process.


That could be separate from the idea of tearing off the webapp 

Re: [whatwg] BWTP for WebSocket transfer protocol

[Jonas Sicking]

On Fri, Aug 7, 2009 at 12:25 AM, Greg Wilkins wrote:
> Maciej Stachowiak wrote:
>> This proposal looks a bit more complicated than the WS protocol, so it
>> may take a bit to digest.
>
> Maciej,
>
> BWTP is indeed more complex that the base websocket protocol
>
> I think this is one of the key differences between the approach taken
> for the websocket protocol, which I think emphasises simplicity of
> implementation starting from scratch.
>
> But if your starting point is a working HTTP client or server, then
> the work needed to implement BWTP should not be too significant,
> as the additional complexities (Header fields and mime encoded
> content) are handle almost identically to HTTP.

cc'ing Wellington who has written a websocket implementation for Firefox.

Would be great to get his feedback for what savings could be done if
we were to use BWTP as transport protocol compared to using websocket.

My impression is like Maciejs, that we wouldn't be able to reuse much
of our current HTTP infrastructure in order to implement BWTP. At
first glance only the header-parsing code would carry over directly,
but that's not many lines of code and so doesn't seem like a big win.

>> For what it's worth, we are not absolutely wedded to the details of
>> either the API or the protocol, but we feel pretty strongly
>> about delivering the basic functionality.
>
> I think everybody is keen on the basic functionality.
>
> But I think it is the non-basic reality that will ultimately
> drive the design of at least the protocol (if not the API).
>
> For example, when there are multiple WebSocket using components
> in the same frame/tab/browser - should they share TCP/IP
> connections to a host or should they multiplex.
>
> I see this as a trade off between additional complexity
> in the protocol for multiplexing vs consuming extra
> network/server resources for potentially many connections.
>
> Another example is compression.  Currently websocket protocol
> supports only utf-8 or undefined binary framing.    Over the
> life of HTTP, there was no compression, then there was compress
> and now gzip is widely supported.  It could be expected that
> new compression algorithms will be developed over the life
> span of websocket and it will be important to be able to
> support them without the need to update the javascript that
> calls the websocket API.

I agree that these are very interesting features. Especially
connection multiplexing is something that I think is a good idea, for
the reasons you've mentioned elsewhere in this thread (multiple
widgets on the same page). But even compression is nice if it was
possible.

My gut feeling on BWTP vs. websocket is that BWTP carries some
unneccesary complexity/overhead by allowing arbitrary headers in each
frame, whereas websocket is unnecessarily low level.

I don't think BWTP gains a lot by using HTTP-like syntax, as I don't
think that in reality a lot of existing HTTP code can be reused.

/ Jonas

Re: [whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

Maciej Stachowiak wrote:
> 
> On Aug 7, 2009, at 12:25 AM, Greg Wilkins wrote:
> 
>>
>> But if your starting point is a working HTTP client or server, then
>> the work needed to implement BWTP should not be too significant,
>> as the additional complexities (Header fields and mime encoded
>> content) are handle almost identically to HTTP.
> 
> From my review of the spec so far, it doesn't look like we'd be able to
> reuse much of our existing HTTP client implementation, at least not
> easily. The general header field parsing may be the same, but that code
> is trivial. The complex parts are the handling of specific headers,
> caching and connection management, and in most http libraries that code
> is not structured in a way that makes it easy to pick and choose. My
> tentative estimation is that the implementation effort for BWTP would be
> considerably higher. That's not to say it's a showstopper, it just means
> there is a tradeoff between additional functionality and implementation
> complexity.

Maceij,

That's valuable feedback.  My experience is mostly the server side
and I think when it comes to connection handling the server has an
easier time of it than the client - so I can see that BWTP would
have more of an impact on the client.

Remember, at this stage BWTP is a thought experiment, so it is
definitely easy to adapt to new ideas or drop features that are
too complex for the benefit they give.

So are there any changes or omissions that you can suggest that
would make a client implementation easier?

For example, I proposed the default header mechanism to address
concerns Ian expressed about per message byte count.However,
this is not something that HTTP does (and we get by with hundreds
of bytes per request), so perhaps we could leave out the default
Header mechanism at the price of more bytes per message?

Also there is the possibility of making features like multiplexing
optional and negotiated.   This would allow  simple non-multiplexing
implementations, but might cause additional complexity in negotiation.
That really comes down to how important people think multiplexing is.
I think that it is moderately important because I can imagine pages
with 10s of individual widgets, each opening a websocket, so my
server will be looking at 10x the number of connections per user.
If users open multiple windows, then it's 20x!   On the server,
connections are pretty cheap, but not that cheap.


cheers

Re: [whatwg] .tags on HTMLCollections

[Jonas Sicking]

On Tue, Jul 28, 2009 at 2:48 PM, Ian Hickson wrote:
> On Mon, 13 Jul 2009, Boris Zbarsky wrote:
>>
>> Ian just pointed out to me that his current draft requires
>> HTMLCollections to implement a tags() method (which seems to do a filter
>> by tagName on the contents of the collection).
>>
>> As far as I can tell, IE, Webkit, and Opera implement this; Gecko does
>> not.  I was wondering whether any of the Webkit or Opera folks could
>> comment on _why_ they implement this?  I haven't seen any uses of this
>> in the wild (outside document.all.tags, but document.all doesn't behave
>> like a normal HTMLCollection in all sorts of other ways either).
>>
>> I'd rather be specifying (and implementing) a smaller DOM API, if that's
>> all that's needed for actual web compat
>
> On Tue, 14 Jul 2009, Maciej Stachowiak wrote:
>>
>> Support for HTMLCollection.tags() in WebKit predates the fork from
>> KHTML. So we don't know why it was originally added.
>
> On Tue, 14 Jul 2009, Boris Zbarsky wrote:
>>
>> I guess the other question is whether you feel it's worth keeping...
>
> On Tue, 14 Jul 2009, Maciej Stachowiak wrote:
>>
>> I don't know of a reason it's needed for collections other than
>> document.all. But it also doesn't seem harmful and I can't say
>> definitively whether it helps anything. I wouldn't object to removing it
>> from the spec, but we probably wouldn't remove it from WebKit short of
>> evidence that it's actually harmful.
>>
>> Perhaps Opera people can shed more light on the matter.
>
> On Thu, 23 Jul 2009, Anne van Kesteren wrote:
>>
>> From what I heard so far it is there because of document.all. If
>> document.all does indeed need to return a separate object as HTML5
>> suggests we can probably remove it from HTMLCollection in due course.
>
> 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.

/ Jonas

Re: [whatwg] Installed Apps

[Jonas Sicking]

2009/7/30 Ian Fette (イアンフェッティ) :
>> That being said, I think there are valid use cases for out-of-band
>> notifications, for example for calendar events or "status update" type
>> applications such as Facebook or Twitter.
>>
>> I'd like to explore whether we can accommodate this notification use case
>> without bringing the full power of the Web platform to bear, and thereby
>> opening up a lot of attack surface on the client. Here's one rough sketch of
>> an idea:
>>
>> * Notification Feeds *
>>
>> Often, web applications would like to give users the option to subscribe
>> to notifications that occur at specific times or in response to server-side
>> events, and for the user to get these UI notifications without a
>> prerequisite that the web app is open or that the browser is running. There
>> may be a desire to do client-side computation as well, but often just the
>> ability to give the user a notification solves the basic user interaction
>> problem.
>>
>> One possible way to address this kind of use case is to let users
>> subscribe to a "feed" of notifications. This feed could use standard
>> syndication formats, such as RSS or Atom. But instead of being displayed in
>> a traditional feed reader, it's displayed in the form of transient
>> notifications (along the lines of Growl on Mac OS X) which are posted for
>> each new event. To allow some pre-scheduling of events, each item can have a
>> date and won't be displayed until that date - this way a calendar can give
>> you your feed of upcoming events and you can still get notifications when
>> offline. In the case of something like email or Twitter, obviously there's
>> no sensible way to get notifications when offline since they depend on
>> unpredeictable server-side activity. There could even be a client-side API
>> that lets a Web app schedule items on a subscribed notification feed from
>> script, to enable scheduling calendar events offline. Each notification
>> would have the option to unsubscribe from the notification feed, to reduce
>> spam potential.
>>
>> Notice that this opens up a lot less attack surface. The user has to
>> actively opt in to subscribing to the notification feed, just as for an RSS
>> feed. This makes it much less likely they end up with a subscription to a
>> shady site. And the notifications are passive data items (probably no script
>> should be allowed in a notification, if the format is HTML and not just
>> plain text), so they open up a lot less security risk. Obviously this is
>> less powerful than the ability to run arbitrary code in the background. But
>> it could address a large chunk of the use cases with much less security
>> risk.
>
> It addresses some use cases (calendar, perhaps), but I would still like to
> be able to e.g. keep my email up to date. Do I need the "full power" /
> "fully general" solution? I don't know, perhaps the push mechanism can be
> structured in a way that it gets into my database or whatever storage
> mechanism I am using for offline data storage?

I agree, however I don't think the solution is to allow a background
webpage or something similar which has the full power of the web
platform, and all the naughty things available to it. Instead I think
it'd be great to have a protocol which allowed asynchronous updates to
a client-side resource (or set of resources). There's nothing that
would prevent this from happening over non-http protocols as well
(such as SMS).

/ Jonas

Re: [whatwg] RTSP in HTML5

[Ian Hickson]

On Fri, 7 Aug 2009, Chytanya Karusala wrote:
> 
> Browsers may not implement it unless it is mandated in the spec.

I assure you that what the spec says has little influence on what the 
browsers do. :-) I encourage you to contact the browser vendors directly 
if you would like to ensure that RTSP support is included in browsers.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Web Workers and postMessage(): Questions

[Jonas Sicking]

On Mon, Aug 3, 2009 at 4:14 PM, Robert O'Callahan wrote:
> On Tue, Aug 4, 2009 at 5:34 AM, Daniel Gredler 
> wrote:
>>
>> I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any
>> comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out
>> there with comments?
>
> I know very little about these issues. Jonas Sicking reads this list and
> would know more.

While I think dealing with cycles could be done, I agree with others
that there are things of higher priority, like supporting ImageData or
Files.

What are the use cases for cyclic data? I'll note that neither JSON
nor XML, which are also data-container formats, opted to allow for
cycles.

/ Jonas

Re: [whatwg] RTSP in HTML5

[Chytanya Karusala]

Thanks for the quick response!

Browsers may not implement it unless it is mandated in the spec. Since
browsers already have HTTP transport, I am afraid the browsers will end up
just supporting HTTP as the only transport for the video tag. Since RTSP is
the major streaming protocol and since HTML5 is supporting multimedia
playback experience within the browser, including RTSP in the spec could
completely do away with the need to have stand-alone RTSP clients installed
or properitery plugins/solutions especially for live streaming. I think it
makes everyone's life a lot easier knowing that there is a standard player
engine present on every PC (through browser) that supports HTTP and RTSP in
multimedia tags instead of worrying about the numerous proproeitery
streaming protocols (based on HTTP) that are coming up with recently.

Thanks,
Chytanya

On Fri, Aug 7, 2009 at 1:29 PM, Ian Hickson  wrote:

> On Fri, 7 Aug 2009, Chytanya Karusala wrote:
> >
> > I thought the video tag in HTML5 will point to a media resource which
> > will be downloaded by the browser and passed on to the player engine
> > inside the browser. If the src tag points to rtsp link the
> > browser/player engine wouldn't know how to handle. By including the rtsp
> > URI support in the video tag, player engine within every browser would
> > act as a rtsp client making better streaming solutions possible (viz..
> > live streaming- in addition to download/progressive download already
> > made possible by video tag)
>
> Ah, I see.
>
> The HTML5 spec doesn't say what transports are expected to be supported;
> there's no reason browsers couldn't support RTSP as well as HTTP.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Microdata Revisited

[Jonas Sicking]

On Mon, Aug 3, 2009 at 2:58 AM, Martin McEvoy wrote:
> Hello All
>
> I have been working on a new proposal for HTML 5 Microdata, I thought you
> might all like to take a look at what I have come up with so far.
>
> please visit http://weborganics.co.uk/test/microdata.html
>
> Any feed back would be nice ;)

I'm in general vary of the use of prefixes here. Maciej summarized
things very nicely in [1]

/ Jonas

[1] http://lists.w3.org/Archives/Public/public-html/2009Jul/0919.html

Re: [whatwg] RTSP in HTML5

[Ian Hickson]

On Fri, 7 Aug 2009, Chytanya Karusala wrote:
>
> I thought the video tag in HTML5 will point to a media resource which 
> will be downloaded by the browser and passed on to the player engine 
> inside the browser. If the src tag points to rtsp link the 
> browser/player engine wouldn't know how to handle. By including the rtsp 
> URI support in the video tag, player engine within every browser would 
> act as a rtsp client making better streaming solutions possible (viz.. 
> live streaming- in addition to download/progressive download already 
> made possible by video tag)

Ah, I see.

The HTML5 spec doesn't say what transports are expected to be supported; 
there's no reason browsers couldn't support RTSP as well as HTTP.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] RTSP in HTML5

[Chytanya Karusala]

I thought the video tag in HTML5 will point to a media resource which will
be downloaded by the browser and passed on to the player engine inside the
browser. If the src tag points to rtsp link the browser/player engine
wouldn't know how to handle. By including the rtsp URI support in the video
tag, player engine within every browser would act as a rtsp client making
better streaming solutions possible (viz.. live streaming-  in addition to
download/progressive download already made possible by video tag)
thanks
Chytanya



On Fri, Aug 7, 2009 at 1:01 PM, Ian Hickson  wrote:

> On Fri, 7 Aug 2009, Chytanya Karusala wrote:
> >
> > I am not sure if this has already been discussed, but is there a plan to
> > include RTSP protocol in HTML5 video tag in addition to HTTP?
>
> In what sense do you mean "include"?
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] RTSP in HTML5

[Ian Hickson]

On Fri, 7 Aug 2009, Chytanya Karusala wrote:
> 
> I am not sure if this has already been discussed, but is there a plan to 
> include RTSP protocol in HTML5 video tag in addition to HTTP?

In what sense do you mean "include"?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] RTSP in HTML5

[Chytanya Karusala]

Hi,

I am not sure if this has already been discussed, but is there a plan to
include RTSP protocol in HTML5 video tag in addition to HTTP?

Thanks,
Chytanya

Re: [whatwg] BWTP for WebSocket transfer protocol

[Maciej Stachowiak]

On Aug 7, 2009, at 12:25 AM, Greg Wilkins wrote:



But if your starting point is a working HTTP client or server, then
the work needed to implement BWTP should not be too significant,
as the additional complexities (Header fields and mime encoded
content) are handle almost identically to HTTP.


From my review of the spec so far, it doesn't look like we'd be able  
to reuse much of our existing HTTP client implementation, at least not  
easily. The general header field parsing may be the same, but that  
code is trivial. The complex parts are the handling of specific  
headers, caching and connection management, and in most http libraries  
that code is not structured in a way that makes it easy to pick and  
choose. My tentative estimation is that the implementation effort for  
BWTP would be considerably higher. That's not to say it's a  
showstopper, it just means there is a tradeoff between additional  
functionality and implementation complexity.


Regards,
Maciej

Re: [whatwg] DOMTokenList feedback

[Jonas Sicking]

On Thu, Jul 30, 2009 at 6:38 PM, Ian Hickson wrote:
> On Mon, 27 Jul 2009, Jonas Sicking wrote:
>> > In general, I try to be as conservative as possible in making changes
>> > to the DOM. Are the algorithms really as complicated as you're making
>> > out? They seem pretty trivial to me.
>>
>> At least in the gecko implementation it's significantly more complex
>> than not normalizing whitespace. The way that the implementation works
>> in gecko is:
>>
>> When a class attribute is set, (during parsing or using setAttribute)
>> we parse the classlist into a list of tokens. We additionally keep
>> around the original string in order to preserve a correct DOM
>> (actually, as an optimization, we only do this if needed).
>>
>> This token-list is then used during Selector matching and during
>> getElementsByClassName.
>>
>> So far I would expect most implementations to match this.
>>
>> It would be very nice if DOMTokenList could be implemented as simply
>> exposing this internal token list. With the recent change to not
>> remove duplicates reading operations like .length and .item(n) maps
>> directly to reading from this token list. All very nice.
>>
>> However writing operations such as .add and .remove requires operating
>> on the string rather than the internal token-list. The current spec
>> requires .remove to duplicate the tokenization process (granted, a
>> pretty simple task) and modify the string while tokenizing. It would be
>> significantly simpler if you could just modify the token-list as needed
>> and then regenerate the string from the token-list.
>
> I've left it as is for now, but if other implementors agree that it would
> be significantly better to change it to normalise whitespace each time, I
> don't feel too strongly about it.

I too am interested in feedback from other implementors.

> (We're agreed that removing would remove all duplicates, and that the
> order would be preserved, right?)

Indeed.

/ Jonas

Re: [whatwg] small element should allow nested elements

[Remy Sharp]

I should add, another argument for using small to wrap, is that  
without it, on a list element, the numerals in the list are larger  
than the the small print text - because the small element is on the  
inner HTML rather than the entire element (which does effect the  
numeric bullets too).


Remy Sharp

On 7 Aug 2009, at 14:19, Remy Sharp wrote:


Hi,

I know Bruce Lawson has mentioned that this has been brought up  
before, but I couldn't find it in the archives (searching "small"),  
so I'd like to bring it up again.


The HTML 5 spec says:

"Small print typically features disclaimers, caveats, legal  
restrictions, or copyrights. Small print is also sometimes used for  
attribution, or for satisfying licensing requirements."


http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-small-element

So I'm making a list of disclaimers for my site:


 You must agree to this term
 And this term too
 And don't break this term
 And don't forget the milk

By reading this, you're agreeing to xyz

To make this valid, and small print text, I need to individually  
wrap the inner HTML of each inline element (li and p elements).   
This is wasteful and very much like the situation that we had with  
the a element when we wanted the whole block to be clickable.


When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo 
 ) all the browsers I've tested it in renders the text as I would  
expect, but it doesn't validate against the HTML 5 parsing rules (as  
you'd expect).


If this element is truly for disclaimers, caveats and restrictions,  
and not stylistically making something small, then it will be  
typically used on blocks of content, be it a single line or multiple  
paragraphs.  As such, it seems sensible to say that the small  
element can have nested block elements within it.


Here's the list of the compatible browsers (I could have done more  
browsers, but I think this test with 10 proves the support is solid):


http://leftlogic.litmusapp.com/pub/a5fa8ed

At time of writing, the last test is still being generated,  
but I've tested Firefox 3.5 manually and it passes ;-)



Cheers,

Remy Sharp
Left Logic

___

I'm running a conference in Brighton on 20-Nov called:

Full Frontal JavaScript Conference
http://2009.full-frontal.org

[whatwg] Textarea wrap=off

[Tab Atkins Jr.]

Proposal

Add the "off" state to the @wrap attribute for textareas.

Explanation
===
The "off" state prevents a textarea from wrapping text at all while
displaying.  Instead, text that is too long for the textarea trigger a
horizontal scrollbar, but stays on one line.  The only way for text to
drop to a new line is with an actual carriage return.

The value of a textarea with wrap=off is the same as wrap=soft.

Reasoning
=
Every UA I've tested (FF3.5, IE7, Opera10B2, Safari4, Chrome2) already
supports it.  They offer slightly different displays of a wrap=off
textarea, but the basic functionality as described above is identical
and seemingly interoperable.  Adding this to the spec shouldn't
require any additional work from the UAs, it would merely be
recognizing and enshrining a facility that is already common to all of
them.

Re: [whatwg] HTML5: compatible with all legacy Web browsers

[Erik Vorhes]

On Fri, Aug 7, 2009 at 8:28 AM, Aryeh Gregor wrote:
> I think the meaning of "compatible with all existing browsers" here is
> that HTML 5 does not *require* authors to break compatibility with any
> existing browser.
>

I agree completely with your interpretation of the phrase. HTML5 is
intended to enhance the web without breaking it, so noting (or even
emphasizing) how it's backwards-compatible is important and useful.

But the phrase should be clarified along similar lines to what you've
articulated. Maybe: "HTML5 can be written in such a way that it is
compatible with all browsers made after X date"?

Erik

Re: [whatwg] HTML5: compatible with all legacy Web browsers

[Aryeh Gregor]

I think the meaning of "compatible with all existing browsers" here is
that HTML 5 does not *require* authors to break compatibility with any
existing browser.  Obviously some new features of HTML 5 will not work
in some existing browsers -- otherwise there could be no new features
in the spec!  But it's designed to support graceful degradation
wherever possible, so that authors can use many of the new features
without breaking compatibility with any existing browser.  This is in
contrast to its erstwhile competitor XHTML 2 -- XHTML 2 cannot be used
in any legacy browsers, ever.

Clearer wording might be like, "HTML5 pages can be written to be
compatible with all legacy Web browsers."  Of course, "all legacy Web
browsers" does need to be construed to exclude Netscape Navigator 3
and such.  If you really want to be picky, it could be "all legacy Web
browsers that still see significant use."

[whatwg] small element should allow nested elements

[Remy Sharp]

Hi,

I know Bruce Lawson has mentioned that this has been brought up  
before, but I couldn't find it in the archives (searching "small"), so  
I'd like to bring it up again.


The HTML 5 spec says:

"Small print typically features disclaimers, caveats, legal  
restrictions, or copyrights. Small print is also sometimes used for  
attribution, or for satisfying licensing requirements."


http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-small-element

So I'm making a list of disclaimers for my site:


  You must agree to this term
  And this term too
  And don't break this term
  And don't forget the milk

By reading this, you're agreeing to xyz

To make this valid, and small print text, I need to individually wrap  
the inner HTML of each inline element (li and p elements).  This is  
wasteful and very much like the situation that we had with the a  
element when we wanted the whole block to be clickable.


When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo 
 ) all the browsers I've tested it in renders the text as I would  
expect, but it doesn't validate against the HTML 5 parsing rules (as  
you'd expect).


If this element is truly for disclaimers, caveats and restrictions,  
and not stylistically making something small, then it will be  
typically used on blocks of content, be it a single line or multiple  
paragraphs.  As such, it seems sensible to say that the small element  
can have nested block elements within it.


Here's the list of the compatible browsers (I could have done more  
browsers, but I think this test with 10 proves the support is solid):


http://leftlogic.litmusapp.com/pub/a5fa8ed

At time of writing, the last test is still being generated, but  
I've tested Firefox 3.5 manually and it passes ;-)



Cheers,

Remy Sharp
Left Logic

___

I'm running a conference in Brighton on 20-Nov called:

Full Frontal JavaScript Conference
http://2009.full-frontal.org

Re: [whatwg] HTML5: compatible with all legacy Web browsers

[Erik Vorhes]

On Fri, Aug 7, 2009 at 5:39 AM, Simon Pieters wrote:
>
> What is it that is not compatible with which browser?
>

Any use of  outside of a  is broken in every
"modern" browser: IE6-8, Firefox 3-3.5, Safari 3-4, and Opera 9-10b
all break in interesting ways. For more details, see Remy Sharp's
"Legend not such a legend anymore"
.

Erik

Re: [whatwg] HTML5: compatible with all legacy Web browsers

[Simon Pieters]

On Thu, 06 Aug 2009 19:49:45 +0200, Elliotte Rusty Harold  
 wrote:



Section 1.7:

"The first such concrete syntax is "HTML5". This is the format
recommended for most authors. It is compatible with all legacy Web
browsers."

I challenge the claim that HTML5 is compatible with *all* legacy Web
browsers.


I guess it depends on the definition of "compatible".



I can produce valid HTML 4 documents today that are not
compatible with *all* legacy Web browsers.


That's irrelevant. Can you produce valid HTML5 documents today that are  
not compatible with all legacy Web browsers?


I guess the following is an example of a valid HTML5 document that is  
incompatible with legacy Web browsers:


   
   
   
   Hello world



I suggest this be weakened
to something like "is compatible with most Web browsers still in
active use today".


What is it that is not compatible with which browser?

--
Simon Pieters
Opera Software

Re: [whatwg] HTML 5 Script Tag

[Stewart Brodie]

Aryeh Gregor  wrote:

> Recentish WebKit does actually respect the self-closing part of the
> 

Re: [whatwg] BWTP for WebSocket transfer protocol

[Greg Wilkins]

Maciej Stachowiak wrote:
> This proposal looks a bit more complicated than the WS protocol, so it
> may take a bit to digest.

Maciej,

BWTP is indeed more complex that the base websocket protocol

I think this is one of the key differences between the approach taken
for the websocket protocol, which I think emphasises simplicity of
implementation starting from scratch.

But if your starting point is a working HTTP client or server, then
the work needed to implement BWTP should not be too significant,
as the additional complexities (Header fields and mime encoded
content) are handle almost identically to HTTP.


> For what it's worth, we are not absolutely wedded to the details of
> either the API or the protocol, but we feel pretty strongly
> about delivering the basic functionality.

I think everybody is keen on the basic functionality.

But I think it is the non-basic reality that will ultimately
drive the design of at least the protocol (if not the API).

For example, when there are multiple WebSocket using components
in the same frame/tab/browser - should they share TCP/IP
connections to a host or should they multiplex.

I see this as a trade off between additional complexity
in the protocol for multiplexing vs consuming extra
network/server resources for potentially many connections.

Another example is compression.  Currently websocket protocol
supports only utf-8 or undefined binary framing.Over the
life of HTTP, there was no compression, then there was compress
and now gzip is widely supported.  It could be expected that
new compression algorithms will be developed over the life
span of websocket and it will be important to be able to
support them without the need to update the javascript that
calls the websocket API.


cheers