Re: [whatwg] canvas paths without a current point.
On Wed, 29 Jul 2009, Dean McNamee wrote: For the curves, I don't really get the point of moveTo()ing to one of the control points. Me either, but at leave for quadratic and bezier curves, that seems to be what browsers do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas context.drawImage clarification
On Tue, Jul 28, 2009 at 4:07 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Tue, Jul 28, 2009 at 1:41 AM, Gregg Tavaresg...@google.com wrote: It's ambiguous because images have a direction. An image that starts at 10 with a width of -5 is not the same as an image that starts at 6 with a width of +5 any more than starting in SF and driving 5 miles south is not the same as starting in Brisbane and driving 5 miles north. The spec doesn't say which interpretation is correct. I think it's extremely clear. The spec gives four points which determine a rectangle, which are in no particular order. The image is rectangular, and is mapped into that rectangle. Rectangles have no orientation, and the operation paint the source region onto the destination region couldn't possibly be interpreted as requiring reorientation of any kind. If it's so clear, why do you think 2 of the 4 browsers that implemented it apparently got it wrong? Would making the spec more explicit have avoided their mis-intepretation? I think you got misled by the diagram, and now aren't reading the normative text of the spec carefully enough -- it's *very* specific (like most of HTML 5).
Re: [whatwg] Stripping newlines from URI attributes
On Thu, 30 Jul 2009 02:49:01 +0200, Kartikaya Gupta lists.wha...@stakface.com wrote: It seems that most browsers do some sort of newline and tab removal from URI attributes. For example, if you have img src=foo bar.jpg browsers will still render the image called foobar.jpg despite the CRLF pair in the middle of the src attribute. The behavior actually seems a bit more complex; quote from one of my co-workers who investigated this: Any chance you could also check whether this applies to CSS, XMLHttpRequest, HTTP Location, etc.? So for I've found that browsers use the same URL processor everywhere (though sometimes the URL character encoding flag is set to UTF-8 and cannot be changed). As such it would be nice to know if that is still true here or whether this is a pre-processing step specific to HTML attribute values. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] HTML5 spin-offs (was: Re: Stripping newlines from URI attributes)
On Thu, 30 Jul 2009 02:49:01 +0200, Kartikaya Gupta lists.wha...@stakface.com wrote: On a related note, I was wondering if all these spin-off specs could be listed somewhere easy to find; it took me a while to locate the web addresses one and I had to use google to find it. Putting a list at, say, http://www.whatwg.org/specs/ would be handy; or even better, the references section in the HTML5 spec could list them. I created an overview here: http://wiki.whatwg.org/wiki/HTML5_spin-offs Not sure where to best link it from. Someone else may figure that out :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] HTML5 History Management
On Wed, Jul 29, 2009 at 7:38 PM, Nathan Hammondnat...@nathanhammond.com wrote:
Clarifications
1. window.history.pushState({}, Title,
/path/to/new/file.html?s=newvalue#newhash) replaces the current document
object with the one specified by the new URL. It then causes the event
popstate to fire immediately after the load event, correct?
No. The above line with change the uri of the existing document to be
http://example.com/path/to/new/file.html?s=newvalue#newhash; (with
the part before 'path' obviously depending on where the original page
lives).
So no network activity takes place and the Document node remains the
same. Also no popstate event is fired.
2. window.history.pushState({}, Title, #newhash) creates a new history
state object with the specified data object, the specified title, the same
document object, and a location object that replaces the existing hash with
#newhash, correct?
Yes.
/ Jonas
Re: [whatwg] An BinaryArchive API for HTML5?
On Thu, 30 Jul 2009 08:49:12 +0200, Gregg Tavares g...@google.com wrote:
What are people's feelings on adding a Binary Archive API to HTML5?
I think it makes more sense to build functionality like this on top of the File
API rather than add more things into HTML5.
It seems like it would be useful if there was browser API that let you
download something like gzipped tar files.
We already have that: XMLHttpRequest.
The API would look something like
var request = createArchiveRequest();
request.open(GET, http://someplace.com/somearchive.tgz;);
request.onfileavailable = doSomethingWithEachFileAsItArrives;
request.send();
I don't think we should introduce a new HTTP API.
function doSomethingWithEachFileAsItArrives(binaryBlob) {
// Load every image in archive
if (binaryBlob.url.substr(-3) == .jpg) {
var image = new Image();
image.src = binaryBlob.toDataURL(); // or something;
...
}
// Look for a specific text file
else if (binaryBlog.url === myspecial.txt) {
// getText only works if binaryBlob is valid utf-8 text.
var text = binaryBlob.getText();
document.getElementById(content).innerHTML = text;
}
}
Having dedicated support for a subset of archiving formats in within the API
for File objects makes sense to me. Latest draft of the File API I know of is
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
and the mailing list would be public-weba...@w3.org.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Stripping newlines from URI attributes
On Wed, Jul 29, 2009 at 5:49 PM, Kartikaya Guptalists.wha...@stakface.com wrote: It seems that most browsers do some sort of newline and tab removal from URI attributes. For example, if you have img src=foo bar.jpg browsers will still render the image called foobar.jpg despite the CRLF pair in the middle of the src attribute. The behavior actually seems a bit more complex; quote from one of my co-workers who investigated this: This behavior doesn't seem to be specced anywhere as far as I can tell. Assuming the WEBADDRESSES spec referred to in HTML5 is the one at http://www.w3.org/html/wg/href/draft.html that only says to trim leading/trailing whitespace and url-encode the rest. This doesn't seem to match existing behavior, so it should probably be updated. How weird. Frankly how insane. While I can believe that some browsers act like this, I would be quite surprised to find that they were compatible with each other. Indeed your tests seem to show they aren't. This is an area where we should not attempt (and probably simply cannot) maintain compatibility with existing browsers. They're just too broken. -- Elliotte Rusty Harold elh...@ibiblio.org
[whatwg] Dates BCE
I note in http://www.whatwg.org/specs/web-apps/current-work/#valid-date-string that Dates before the year zero can't be represented as a datetime in this version of HTML. This seems a serious omission. Why can we represent the birth of Nero but not the birth of Julius Caesar? Are there plans to rectify it? -- Elliotte Rusty Harold elh...@ibiblio.org
Re: [whatwg] Stripping newlines from URI attributes
On Thu, Jul 30, 2009 at 2:37 PM, Elliotte Rusty Haroldelh...@ibiblio.org wrote: On Wed, Jul 29, 2009 at 5:49 PM, Kartikaya Guptalists.wha...@stakface.com wrote: It seems that most browsers do some sort of newline and tab removal from URI attributes. For example, if you have img src=foo bar.jpg browsers will still render the image called foobar.jpg despite the CRLF pair in the middle of the src attribute. [...] This is an area where we should not attempt (and probably simply cannot) maintain compatibility with existing browsers. They're just too broken. We should attempt to maintain compatibility with existing content, and whitespace in URI attributes seems very common in existing content, e.g.: http://www.topdogphotos.com/photo-gallery/gallery11.html (newlines in a href, img src) http://www.sprig.com/coyuchi_george_or_thor_hooded_baby_towel (tabs and #xD;#xA; in img src) and loads more. -- Philip Taylor exc...@gmail.com
Re: [whatwg] Dates BCE
2009/7/30 Elliotte Rusty Harold elh...@ibiblio.org I note in http://www.whatwg.org/specs/web-apps/current-work/#valid-date-string that Dates before the year zero can't be represented as a datetime in this version of HTML. This seems a serious omission. Why can we represent the birth of Nero but not the birth of Julius Caesar? Are there plans to rectify it? I sure hope there are! Historians and classicists are increasingly publishing to the web, and being unable to mark up years BCE in HTML 5 would hinder this. That said, marking up a year, say 1992 AD, (as opposed to a specific day within a specific month within a specific year, e.g. 3rd September 1992) also seems to be hard or impossible in HTML 5... unless I've misread the spec.
Re: [whatwg] Dates BCE
On Thu, 30 Jul 2009 15:05:10 +0100, Sam Kuper sam.ku...@uclmail.net wrote: I sure hope there are! Historians and classicists are increasingly publishing to the web, and being unable to mark up years BCE in HTML 5 would hinder this. That said, marking up a year, say 1992 AD, (as opposed to a specific day within a specific month within a specific year, e.g. 3rd September 1992) also seems to be hard or impossible in HTML 5... unless I've misread the spec. Orthodoxy has it that there is no use case for marking up an ancient date or fuzzy date like June 2009 using time. I disagree, and this has been discussed many times before. Do you have any concrete use cases or examples of how marking these up using time would be necessary? -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] HTML5 History Management
Hey Jonas et al.:
Thanks for the reply, forgive my disbelief on Clarification 1. :) If
I'm completely with you, that is entirely unexpected on my part (and
I've read this part of the spec a few times). Is this to imply that,
no matter what the arguments to pushState(), if the path is relative
to the current URL there will be no request for a new document and no
user-agent initiated network activity?
This is a behavior I'm fine with and will meet my needs just as well,
I was simply expecting to have to use the approach from Clarification
2 in order to retain my document object. It does however lend itself
to some confusion when paired with user agents that don't yet support
the history portions of the spec as they will have to be handled with
hash-based addressing while those that support pushState() will have
more sane URLs--but that is no matter in the grand scheme of things.
Also, that would imply that the popstate only fires when you're
navigating through history. Is that correct?
Thanks!
Nathan
On Jul 30, 2009, at 4:42 AM, Jonas Sicking wrote:
On Wed, Jul 29, 2009 at 7:38 PM, Nathan Hammondnat...@nathanhammond.com
wrote:
Clarifications
1. window.history.pushState({}, Title,
/path/to/new/file.html?s=newvalue#newhash) replaces the current
document
object with the one specified by the new URL. It then causes the
event
popstate to fire immediately after the load event, correct?
No. The above line with change the uri of the existing document to be
http://example.com/path/to/new/file.html?s=newvalue#newhash; (with
the part before 'path' obviously depending on where the original page
lives).
So no network activity takes place and the Document node remains the
same. Also no popstate event is fired.
2. window.history.pushState({}, Title, #newhash) creates a new
history
state object with the specified data object, the specified title,
the same
document object, and a location object that replaces the existing
hash with
#newhash, correct?
Yes.
/ Jonas
Re: [whatwg] Dates BCE
On Thu, Jul 30, 2009 at 8:43 AM, Elliotte Rusty Haroldelh...@ibiblio.org wrote: I note in http://www.whatwg.org/specs/web-apps/current-work/#valid-date-string that Dates before the year zero can't be represented as a datetime in this version of HTML. This seems a serious omission. Why can we represent the birth of Nero but not the birth of Julius Caesar? Are there plans to rectify it? There have been *long* debates on this. Basically, it all revolves around calendars, and the fact that, before the current Gregorian calendar was adopted, dates were *much* more complicated, and hard to pin down in a definite way. As noted in the spec, the current Gregorian calendar was first adopted in some countries in the 16th century, though it wasn't fully adopted everywhere until the mid-20th century. For dates, before that, you have to do some conversion to get it on track with regards to our current calendar. As you go further back the conversion gets more difficult, depending on archeology, essentially, and eventually becomes impossible. The only reason the spec blesses dates back to 0 is because it's easy to do when you're already blessing dates back to 1500 or so. It doesn't require a single extra step in the algorithm. By the time you actually *hit* that point, though, you're already pretty much in the have to be a historical scholar, and be pretty lucky, to figure this out range. In addition, note the use-case for time. It is *not* meant to be a general text-level semantic for dates. It's designed to make it easy to machine-parse dates around the current era for use in calendar applications, etc. (For example, one could automatically save an event from a page onto your calendar.) Plotting the birth of Julius Ceasar on a calendar may be an interesting way to bring that time period to life, but it's not really useful in the way that actual calendar applications are intended. Note: you *can* still mark up years BCE in HTML5! pThis event happened in 5 BCE/p is perfectly valid. There's no easy machine-parseable metadata in there, but so far there hasn't been much presented that would require such a thing. As Bruce said, if you have some concrete use-cases for why you need to mark-up the date in a machine-readable manner, rather than simply having it within the text of your site, please share! ~TJ
Re: [whatwg] HTML5 History Management
Jonas,
That is my interpretation too. But I think it's a little unclear whether
that means that the UA should update any Location fields in the UI. I
understand that this may be optional or outside the scope, but I think that
it should still be mentioned.
Now if the UA is suppose to update the Location field, shouldn't push state
URL be subject to same-domain policies? Is that defined clearly?
Otherwise, this can be used during phishing attacks.
Sebastian
On Thu, Jul 30, 2009 at 4:13 PM, Nathan Hammond nat...@nathanhammond.comwrote:
Hey Jonas et al.:
Thanks for the reply, forgive my disbelief on Clarification 1. :) If I'm
completely with you, that is entirely unexpected on my part (and I've read
this part of the spec a few times). Is this to imply that, no matter what
the arguments to pushState(), if the path is relative to the current URL
there will be no request for a new document and no user-agent initiated
network activity?
This is a behavior I'm fine with and will meet my needs just as well, I was
simply expecting to have to use the approach from Clarification 2 in order
to retain my document object. It does however lend itself to some confusion
when paired with user agents that don't yet support the history portions of
the spec as they will have to be handled with hash-based addressing while
those that support pushState() will have more sane URLs--but that is no
matter in the grand scheme of things.
Also, that would imply that the popstate only fires when you're navigating
through history. Is that correct?
Thanks!
Nathan
On Jul 30, 2009, at 4:42 AM, Jonas Sicking wrote:
On Wed, Jul 29, 2009 at 7:38 PM, Nathan Hammondnat...@nathanhammond.com
wrote:
Clarifications
1. window.history.pushState({}, Title,
/path/to/new/file.html?s=newvalue#newhash) replaces the current
document
object with the one specified by the new URL. It then causes the event
popstate to fire immediately after the load event, correct?
No. The above line with change the uri of the existing document to be
http://example.com/path/to/new/file.html?s=newvalue#newhash; (with
the part before 'path' obviously depending on where the original page
lives).
So no network activity takes place and the Document node remains the
same. Also no popstate event is fired.
2. window.history.pushState({}, Title, #newhash) creates a new
history
state object with the specified data object, the specified title, the
same
document object, and a location object that replaces the existing hash
with
#newhash, correct?
Yes.
/ Jonas
Re: [whatwg] Canvas context.drawImage clarification
Gregg Tavares wrote: If it's so clear, why do you think 2 of the 4 browsers that implemented it apparently got it wrong? Because the implementations preceded the current spec text; they were just implementing something like Apple's Canvas without trying too hard to be compatible in edge cases. Would making the spec more explicit have avoided their mis-intepretation? Given the above, unlikely. -Boris
Re: [whatwg] HTML5 History Management
Sorry, same domain policy is clearly defined. I just missed it.
Compare the resulting absolute URL to the document's address. If any part
of these two URLs differ other than the path, query, and fragment
components, then raise a SECURITY_ERR exception and abort the pushState()
steps.
On Thu, Jul 30, 2009 at 4:27 PM, Sebastian Markbåge
sebast...@calyptus.euwrote:
Jonas,
That is my interpretation too. But I think it's a little unclear whether
that means that the UA should update any Location fields in the UI. I
understand that this may be optional or outside the scope, but I think that
it should still be mentioned.
Now if the UA is suppose to update the Location field, shouldn't push state
URL be subject to same-domain policies? Is that defined clearly?
Otherwise, this can be used during phishing attacks.
Sebastian
On Thu, Jul 30, 2009 at 4:13 PM, Nathan Hammond
nat...@nathanhammond.comwrote:
Hey Jonas et al.:
Thanks for the reply, forgive my disbelief on Clarification 1. :) If I'm
completely with you, that is entirely unexpected on my part (and I've read
this part of the spec a few times). Is this to imply that, no matter what
the arguments to pushState(), if the path is relative to the current URL
there will be no request for a new document and no user-agent initiated
network activity?
This is a behavior I'm fine with and will meet my needs just as well, I
was simply expecting to have to use the approach from Clarification 2 in
order to retain my document object. It does however lend itself to some
confusion when paired with user agents that don't yet support the history
portions of the spec as they will have to be handled with hash-based
addressing while those that support pushState() will have more sane
URLs--but that is no matter in the grand scheme of things.
Also, that would imply that the popstate only fires when you're navigating
through history. Is that correct?
Thanks!
Nathan
On Jul 30, 2009, at 4:42 AM, Jonas Sicking wrote:
On Wed, Jul 29, 2009 at 7:38 PM, Nathan Hammondnat...@nathanhammond.com
wrote:
Clarifications
1. window.history.pushState({}, Title,
/path/to/new/file.html?s=newvalue#newhash) replaces the current
document
object with the one specified by the new URL. It then causes the event
popstate to fire immediately after the load event, correct?
No. The above line with change the uri of the existing document to be
http://example.com/path/to/new/file.html?s=newvalue#newhash; (with
the part before 'path' obviously depending on where the original page
lives).
So no network activity takes place and the Document node remains the
same. Also no popstate event is fired.
2. window.history.pushState({}, Title, #newhash) creates a new
history
state object with the specified data object, the specified title, the
same
document object, and a location object that replaces the existing hash
with
#newhash, correct?
Yes.
/ Jonas
Re: [whatwg] HTML5 History Management
Sebastian,
The same-origin is pretty clearly specified, I've included the excerpt
from the spec below. Your suggestion for clarity on updating Location
fields in the the UI would be a part of step five in the description
of pushState in section 6.10.2 is a good one. Ian, I feel like this
counts as a possible action item.
Nathan
***
Possible Action Items
1. Clarify how the user agent uses the calculated location value from
the pushState description step 2 in section 6.10.2 in terms of being
reflected in the Location object.
It is my opinion that this URL should be reflected in the Location
value. This would imply that it would be reflected in the location bar
of user agents that have this as part of their UI. It seems that the
place to include this clarification would be the pushState description
step 5 in section 6.10.2
2. Clarify that pushState() does not cause navigation.
I read the spec quite a few times and still got this wrong,
apparently. Making this completely clear would not hurt.
***
If a third argument is specified, run these substeps:
1. Resolve the value of the third argument, relative to the first
script's base URL.
2. If that fails, raise a SECURITY_ERR exception and abort the
pushState() steps.
3. Compare the resulting absolute URL to the document's address. If
any part of these two URLs differ other than the path, query, and
fragment components, then raise a SECURITY_ERR exception and abort
the pushState() steps.
For the purposes of the comparison in the above substeps, the path
and query components can only be the same if the URLs use a
hierarchical scheme.
On Jul 30, 2009, at 10:27 AM, Sebastian Markbåge wrote:
Jonas,
That is my interpretation too. But I think it's a little unclear
whether that means that the UA should update any Location fields in
the UI. I understand that this may be optional or outside the scope,
but I think that it should still be mentioned.
Now if the UA is suppose to update the Location field, shouldn't
push state URL be subject to same-domain policies? Is that defined
clearly?
Otherwise, this can be used during phishing attacks.
Sebastian
On Thu, Jul 30, 2009 at 4:13 PM, Nathan Hammond nat...@nathanhammond.com
wrote:
Hey Jonas et al.:
Thanks for the reply, forgive my disbelief on Clarification 1. :) If
I'm completely with you, that is entirely unexpected on my part (and
I've read this part of the spec a few times). Is this to imply that,
no matter what the arguments to pushState(), if the path is relative
to the current URL there will be no request for a new document and
no user-agent initiated network activity?
This is a behavior I'm fine with and will meet my needs just as
well, I was simply expecting to have to use the approach from
Clarification 2 in order to retain my document object. It does
however lend itself to some confusion when paired with user agents
that don't yet support the history portions of the spec as they will
have to be handled with hash-based addressing while those that
support pushState() will have more sane URLs--but that is no matter
in the grand scheme of things.
Also, that would imply that the popstate only fires when you're
navigating through history. Is that correct?
Thanks!
Nathan
On Jul 30, 2009, at 4:42 AM, Jonas Sicking wrote:
On Wed, Jul 29, 2009 at 7:38 PM, Nathan Hammondnat...@nathanhammond.com
wrote:
Clarifications
1. window.history.pushState({}, Title,
/path/to/new/file.html?s=newvalue#newhash) replaces the current
document
object with the one specified by the new URL. It then causes the event
popstate to fire immediately after the load event, correct?
No. The above line with change the uri of the existing document to be
http://example.com/path/to/new/file.html?s=newvalue#newhash; (with
the part before 'path' obviously depending on where the original page
lives).
So no network activity takes place and the Document node remains the
same. Also no popstate event is fired.
2. window.history.pushState({}, Title, #newhash) creates a new
history
state object with the specified data object, the specified title,
the same
document object, and a location object that replaces the existing
hash with
#newhash, correct?
Yes.
/ Jonas
Re: [whatwg] Fwd: Make quoted attributes a conformance criterion
On Mon, Jul 27, 2009 at 3:29 AM, Jeremy Keithjer...@adactio.com wrote: I concur. And I say that as someone who likes the XHTML-like syntax (always closing tags, always quoting attributes, etc.). I don't think my personal preference for writing markup should be enforced in the spec; it should be enforced in the lint tools. If the HTML 5 spec actually enforced anything, I would agree with you. However the HTML 5 spec differs radically from the specs for JavaScript, C++, Java, and so forth in that browsers will still accept non-conforming documents and hopefully parse and render them in a defined way. Making non-quoted attributes non-conformant is more akin to a lint suggestion than a hard and fast ruie. There is no such thing as a compile error in HTML 5. The worst an author will get is a warning, and a reader won't even see that. -- Elliotte Rusty Harold elh...@ibiblio.org
Re: [whatwg] Dates BCE
2009/7/30 Bruce Lawson bru...@opera.com On Thu, 30 Jul 2009 15:05:10 +0100, Sam Kuper sam.ku...@uclmail.net wrote: I sure hope there are! Historians and classicists are increasingly publishing to the web, and being unable to mark up years BCE in HTML 5 would hinder this. That said, marking up a year, say 1992 AD, (as opposed to a specific day within a specific month within a specific year, e.g. 3rd September 1992) also seems to be hard or impossible in HTML 5... unless I've misread the spec. Orthodoxy has it that there is no use case for marking up an ancient date or fuzzy date like June 2009 using time. I disagree, and this has been discussed many times before. Do you have any concrete use cases or examples of how marking these up using time would be necessary? Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Exactly the same sort of situation could easily arise when marking up BCE materials, although in this case one would likely have even less information (if any) about which day of the year was being used, so it would be even more crucial to be able to mark up dates in a way that just specifies the year but leaves the month and day undefined. Flexibility is crucial here and since it need not come at the expense of parseability, it should be provided for. Best, Sam
Re: [whatwg] Dates BCE
On Thu, Jul 30, 2009 at 10:34 AM, Sam Kupersam.ku...@uclmail.net wrote: 2009/7/30 Bruce Lawson bru...@opera.com On Thu, 30 Jul 2009 15:05:10 +0100, Sam Kuper sam.ku...@uclmail.net wrote: I sure hope there are! Historians and classicists are increasingly publishing to the web, and being unable to mark up years BCE in HTML 5 would hinder this. That said, marking up a year, say 1992 AD, (as opposed to a specific day within a specific month within a specific year, e.g. 3rd September 1992) also seems to be hard or impossible in HTML 5... unless I've misread the spec. Orthodoxy has it that there is no use case for marking up an ancient date or fuzzy date like June 2009 using time. I disagree, and this has been discussed many times before. Do you have any concrete use cases or examples of how marking these up using time would be necessary? Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Now, here's the million-dollar question: Why do you need time or something like it for these dates? You seem to have them marked up quite fine as it is. ~TJ
Re: [whatwg] HTMLInputElement, date State, and Complexity
On Thu, Jul 30, 2009 at 6:10 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: On Thu, Jul 30, 2009 at 12:54 AM, Garrett Smithdhtmlkitc...@gmail.com wrote: HTML 5 defines input type=date as an input state. This is implemented in at least one userAgent (Opera). Which other browsers have implemented that? No one else, in their public releases. I don't keep track of nightlies much, so I'm not sure if anyone has the functionality sitting there waiting to be included. It seems like the added value to the programmer for valueAsDate appears to be convenience method to format to/parse from ISO 8601, but place on input as a behavior property, and working only when the input is in the date state. For setting[1], the convenience appears to be to set a date value when the Date's [[value]] is valid, although a valid date does not seem to be mentioned, much less clearly defined, and the reference links to [GREGORIAN] are broken[1]. I can't see much other reason for having valueAsDate. Am I missing something? [1]http://www.whatwg.org/specs/web-apps/current-work/#valid-date-string Do you need much more reason than that it lets you conveniently convert between the date string and a Date? Yes, I think more reason is needed. I did not see a definition of a Date in HTML 5 but it seems out of place. A utility method to convert between string and the (not defined) Date is out of place for HTML. valueAsDate is a utility method. valueAsDate adds complexity. It is out of place. It doesn't add much value. Developers will still need a fallback. Methods for formatting Date/parsing string don't belong on HTMLInputElement. ~TJ
Re: [whatwg] Dates BCE
2009/7/30 Tab Atkins Jr. jackalm...@gmail.com On Thu, Jul 30, 2009 at 10:34 AM, Sam Kupersam.ku...@uclmail.net wrote: Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Now, here's the million-dollar question: Why do you need time or something like it for these dates? You seem to have them marked up quite fine as it is. 1) Machine readability. 2) Consistency across websites that mark up dates.
Re: [whatwg] Dates BCE
On Thu, Jul 30, 2009 at 11:12 AM, Sam Kupersam.ku...@uclmail.net wrote: 2009/7/30 Tab Atkins Jr. jackalm...@gmail.com On Thu, Jul 30, 2009 at 10:34 AM, Sam Kupersam.ku...@uclmail.net wrote: Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Now, here's the million-dollar question: Why do you need time or something like it for these dates? You seem to have them marked up quite fine as it is. 1) Machine readability. This begs the question. Why do you need machine readability for the dates in the Darwin journals? More specifically, why do you need machine readability in a standardized fashion currently expected to be used primarily for adding dates to calendars? 2) Consistency across websites that mark up dates. What form of consistency? Date format consistency? This varies by use-case, region, and language. Machine-format consistency? You then have to answer why such consistency is important - what does it let you *do*? ~TJ
Re: [whatwg] Dates BCE
At 17:12 +0100 30/07/09, Sam Kuper wrote: 2009/7/30 Tab Atkins Jr. mailto:jackalm...@gmail.comjackalm...@gmail.com On Thu, Jul 30, 2009 at 10:34 AM, Sam Kupermailto:sam.ku...@uclmail.netsam.ku...@uclmail.net wrote: Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.htmlhttp://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.htmlhttp://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.htmlhttp://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Now, here's the million-dollar question: Why do you need time or something like it for these dates? You seem to have them marked up quite fine as it is. 1) Machine readability. 2) Consistency across websites that mark up dates. Quite. We've had this debate before and Ian decided that it might be confusing to apply a dating system to days when that dating system was not in effect on those days, I think. Against that, one has to realize that the label of the day before X is well-defined for the day before the introduction of the Gregorian calendar, and iteratively going back to year 1, year 0, year -1, and so on. And it would be nice to have a standard way of labelling dates in historical documents so that they are comparable; I am reminded of Kilngaman's book in which he has parallel chapters for China and Rome in the first century CE http://www.amazon.com/First-Century-Emporers-Gods-Everyman/dp/0785822569/ref=sr_1_1?ie=UTF8s=booksqid=1248970679sr=8-1. It would be nice if one could determine that two events in separate documents were essentially contemporary, despite being labeled in the original text in different ways. However, whether the spec. formally blesses using time like this may not be very relevant, as it can be done textually with or without the blessing. -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Dates BCE
At 11:16 -0500 30/07/09, Tab Atkins Jr. wrote: 1) Machine readability. This begs the question. raises the question. begging questions is assuming the answer in the premise of the question. Why do you need machine readability for the dates in the Darwin journals? More specifically, why do you need machine readability in a standardized fashion currently expected to be used primarily for adding dates to calendars? It allows you to build databases with timelines, that span documents on the web from diverse sources. 2) Consistency across websites that mark up dates. What form of consistency? Date format consistency? This varies by use-case, region, and language. Machine-format consistency? You then have to answer why such consistency is important - what does it let you *do*? It would allow you to determine that *this* event reported in an arabic text with a date referring to a caliphate was actually almost certainly *before* this *other* event reported in a byzantine text with a date that is on the indiction cycle. The experts in arabic and byzantine texts individually might well have the skills to convert these dates to a uniform day-labelling system, whereas the interested reader might have the skills in one or the other, but maybe not both (or perhaps even, neither). -- David Singer Multimedia Standards, Apple Inc.
Re: [whatwg] Dates BCE
2009/7/30 Tab Atkins Jr. jackalm...@gmail.com On Thu, Jul 30, 2009 at 11:12 AM, Sam Kupersam.ku...@uclmail.net wrote: 2009/7/30 Tab Atkins Jr. jackalm...@gmail.com On Thu, Jul 30, 2009 at 10:34 AM, Sam Kupersam.ku...@uclmail.net wrote: Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Now, here's the million-dollar question: Why do you need time or something like it for these dates? You seem to have them marked up quite fine as it is. 1) Machine readability. This begs the question. Why do you need machine readability for the dates in the Darwin journals? More specifically, why do you need machine readability in a standardized fashion currently expected to be used primarily for adding dates to calendars? For projects like the Darwin Correspondence Project, machine readable HTML markup of dates might well simplify the various rather fragile and complex custom date search mechanisms these projects have historically tended to use, allowing users to access materials more easily and making APIs to such online corpora easier to create. 2) Consistency across websites that mark up dates. What form of consistency? Date format consistency? This varies by use-case, region, and language. Machine-format consistency? You then have to answer why such consistency is important - what does it let you *do*? Suppose you wanted to mash up the Darwin correspondence data with a SIMILE Timeline[1], it would help if the correspondence data was (more) machine-readable. Now suppose you also wanted to add some diary entries[1] to the same timeline, so that you could instantly visualise when letters were written vs when diary entries were written. This would be much easier if both the two websites from which you were sourcing your data used a consistent, machine-readable date format. [1]http://www.simile-widgets.org/timeline/ [2]http://darwin-online.org.uk/content/frameset?itemID=F1925viewtype=textpageseq=1
Re: [whatwg] Dates BCE
2009/7/30 David Singer sin...@apple.com: Quite. We've had this debate before and Ian decided that it might be confusing to apply a dating system to days when that dating system was not in effect on those days, I think. If by confusing you mean sufficiently confusing that it needs to be avoided, then the proleptic Gregorian calendar would not be suitable for use in HTML5. Yet it has been adopted for HTML5. So either the confusion is tolerable or the reasoning has been inconsistent. I assume the former, and actually I think that using the proleptic Gregorian calendar *decreases* confusion by creating a mutually-agreed neutral vocabulary for dates that other calendars can be translated from and to, thus reducing the total number of mappings needed between calendars if all calendars are to be mappable to each other. Against that, one has to realize that the label of the day before X is well-defined for the day before the introduction of the Gregorian calendar, and iteratively going back to year 1, year 0, year -1, and so on. And it would be nice to have a standard way of labelling dates in historical documents so that they are comparable; I am reminded of Kilngaman's book in which he has parallel chapters for China and Rome in the first century CE http://www.amazon.com/First-Century-Emporers-Gods-Everyman/dp/0785822569/ref=sr_1_1?ie=UTF8s=booksqid=1248970679sr=8-1. It would be nice if one could determine that two events in separate documents were essentially contemporary, despite being labeled in the original text in different ways. It's not simply nice, it's a necessity for accurate automated processing of historical or other non-Gregorian temporal information. However, whether the spec. formally blesses using time like this may not be very relevant, as it can be done textually with or without the blessing. By textually, do you mean manually? If so, many exciting possibilities in online historical research would be rendered quite impractical (as they are currently) simply because of the massive amount of time that would be required to manually process each date conversion. This is a *very* real problem.
Re: [whatwg] Dates BCE
On Thu, Jul 30, 2009 at 11:34 AM, David Singersin...@apple.com wrote: At 11:16 -0500 30/07/09, Tab Atkins Jr. wrote: 1) Machine readability. This begs the question. raises the question. begging questions is assuming the answer in the premise of the question. I meant it in the sense you specify. It begs the question by giving machine readability as a reason for allowing it in time, when the question is posed was why do you need machine readability? Why do you need machine readability for the dates in the Darwin journals? More specifically, why do you need machine readability in a standardized fashion currently expected to be used primarily for adding dates to calendars? It allows you to build databases with timelines, that span documents on the web from diverse sources. This seems like a decent use-case to consider. You want to search the web using temporal data as a search parameter in order to, for instance, create a timeline. 2) Consistency across websites that mark up dates. What form of consistency? Date format consistency? This varies by use-case, region, and language. Machine-format consistency? You then have to answer why such consistency is important - what does it let you *do*? It would allow you to determine that *this* event reported in an arabic text with a date referring to a caliphate was actually almost certainly *before* this *other* event reported in a byzantine text with a date that is on the indiction cycle. The experts in arabic and byzantine texts individually might well have the skills to convert these dates to a uniform day-labelling system, whereas the interested reader might have the skills in one or the other, but maybe not both (or perhaps even, neither). All right, so another use-case: you want to easily compare ancient dates across the web, even if they're written in different and possibly unfamiliar dating systems. ~TJ
Re: [whatwg] Dates BCE
Can the historical-timeline community perhaps work with a microformat for such things, so that we can standardize on the basis of experience using the technology in the field, rather than on speculative uses? Mike
Re: [whatwg] Dates BCE
On Thu, Jul 30, 2009 at 11:36 AM, Sam Kupersam.ku...@uclmail.net wrote: 2009/7/30 Tab Atkins Jr. jackalm...@gmail.com On Thu, Jul 30, 2009 at 11:12 AM, Sam Kupersam.ku...@uclmail.net wrote: 2009/7/30 Tab Atkins Jr. jackalm...@gmail.com On Thu, Jul 30, 2009 at 10:34 AM, Sam Kupersam.ku...@uclmail.net wrote: Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Now, here's the million-dollar question: Why do you need time or something like it for these dates? You seem to have them marked up quite fine as it is. 1) Machine readability. This begs the question. Why do you need machine readability for the dates in the Darwin journals? More specifically, why do you need machine readability in a standardized fashion currently expected to be used primarily for adding dates to calendars? For projects like the Darwin Correspondence Project, machine readable HTML markup of dates might well simplify the various rather fragile and complex custom date search mechanisms these projects have historically tended to use, allowing users to access materials more easily and making APIs to such online corpora easier to create. Within a single project, it seems like you would use a database search. This is completely independent of how it gets marked up in the HTML. APIs especially will depend on data returned from a database. time is only relevant in these cases if you're screen-scraping. 2) Consistency across websites that mark up dates. What form of consistency? Date format consistency? This varies by use-case, region, and language. Machine-format consistency? You then have to answer why such consistency is important - what does it let you *do*? Suppose you wanted to mash up the Darwin correspondence data with a SIMILE Timeline[1], it would help if the correspondence data was (more) machine-readable. Now suppose you also wanted to add some diary entries[1] to the same timeline, so that you could instantly visualise when letters were written vs when diary entries were written. This would be much easier if both the two websites from which you were sourcing your data used a consistent, machine-readable date format. [1]http://www.simile-widgets.org/timeline/ [2]http://darwin-online.org.uk/content/frameset?itemID=F1925viewtype=textpageseq=1 Nice combination of use-cases here: You want to have an app that can aggregate arbitrary historical data from multiple sources to produce, for example, timelines. ~TJ
Re: [whatwg] Dates BCE
On Thu, Jul 30, 2009 at 11:56 AM, Mike Shavermike.sha...@gmail.com wrote: Can the historical-timeline community perhaps work with a microformat for such things, so that we can standardize on the basis of experience using the technology in the field, rather than on speculative uses? I'd actually advise against trying to push this to the Microformats group. They're about marking up visible data in such a way that a machine can parse it. This discussion so far seems to be about taking a visible date (or date range, possibly fuzzy) in an arbitrary calendar, and marking it up with an invisible date in the proleptic gregorian calendar, with support for ranges and fuzziness. ~TJ
Re: [whatwg] Dates BCE
2009/7/30 Tab Atkins Jr. jackalm...@gmail.com: On Thu, Jul 30, 2009 at 11:56 AM, Mike Shavermike.sha...@gmail.com wrote: Can the historical-timeline community perhaps work with a microformat for such things, so that we can standardize on the basis of experience using the technology in the field, rather than on speculative uses? I'd actually advise against trying to push this to the Microformats group. They're about marking up visible data in such a way that a machine can parse it. This discussion so far seems to be about taking a visible date (or date range, possibly fuzzy) in an arbitrary calendar, and marking it up with an invisible date in the proleptic gregorian calendar, with support for ranges and fuzziness. Spot on.
Re: [whatwg] Dates BCE
On Thu, 30 Jul 2009 19:01:33 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Jul 30, 2009 at 11:56 AM, Mike Shavermike.sha...@gmail.com wrote: Can the historical-timeline community perhaps work with a microformat for such things, so that we can standardize on the basis of experience using the technology in the field, rather than on speculative uses? I'd actually advise against trying to push this to the Microformats group. They're about marking up visible data in such a way that a machine can parse it. This discussion so far seems to be about taking a visible date (or date range, possibly fuzzy) in an arbitrary calendar, and marking it up with an invisible date in the proleptic gregorian calendar, with support for ranges and fuzziness. It doesn't have to go through the microformats (lowercase m) group. Everyone can invent class conventions if they so desire. In any case, HTML5 also provides Microdata which could be used for this. I very much agree that experimenting with this before standardizing is the right thing to do. (That's how time came to be.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiakm...@apple.com wrote: Here's some security risks I've thought about, for persistent workers and persistent background pages: great list of risks Thanks for the list, Maciej. However, Firefox extensions today have all of the same problems. Do you consider the permission UI in Firefox insufficient? Given Safari's extension model, I'm going to guess the answer is yes. The fact that FF has extensions, however, at least shows that one browser vendor believes that sufficient permission UI exists. Michael
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiakm...@apple.com wrote: * 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 This is an interesting idea. The lack of push updates, though, would make it much less useful than it could be. Here's a rough sketch of a more far-out idea: What if all browsers were XMPP clients and stanzas could be sent to display notifications? The attack surface would still be low, but you'd get realtime updates. Instead of subscribing to a feed of notifications, the user accepts what is essentially a chat invitation from the site. Like normal XMPP invitations, this would be revocable at any time. Lots of issues to work out, but you'd get realtime for free. Michael
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Thu, Jul 30, 2009 at 10:18 AM, Michael Davidson m...@google.com wrote: On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiakm...@apple.com wrote: Here's some security risks I've thought about, for persistent workers and persistent background pages: great list of risks Thanks for the list, Maciej. However, Firefox extensions today have all of the same problems. Do you consider the permission UI in Firefox insufficient? Given Safari's extension model, I'm going to guess the answer is yes. The fact that FF has extensions, however, at least shows that one browser vendor believes that sufficient permission UI exists. Maciej said this at the end of original email. I do think offering a feature like this in the context of an application or extension style install experience might be acceptable - specifically an experience that is explicitly initiated by the user with multiple affirmative steps. But web features are not usually designed around such an expectation, usually this is the hallmark of a proprietary platform, at times also including central vetting and revocation capabilities. Does that answer your question?
Re: [whatwg] An BinaryArchive API for HTML5?
On Thu, Jul 30, 2009 at 6:13 AM, Sebastian
Markbågesebast...@calyptus.eu wrote:
This suggestion seems similar to Digg's Stream project that uses multipart
documents: http://github.com/digg/stream
While it would be nice to have a way to parse and handle this in JavaScript,
it shouldn't be JavaScript's responsibility to work with large object data
and duplicating it as in-memory data strings.
The real issue here is the overhead of each additional HTTP request for
those thousands of objects. But that's useful for all parts of the spec if
you can download it as a single package even without JavaScript. Images,
CSS, background-images, JavaScript, etc. Currently you can include graphics
as data URLs in CSS. Using a package you could package whole widgets (or
apps) as a single request.
I'd suggest that this belongs in a lower level API such as the URIs and
network stack for the tags. You could specify a file within an archive by
adding an hash with the filename to the URI:
img src=http://someplace.com/somearchive.tgz#myimage.jpg; /
style type=text/css
#id { background-image:
url(http://someplace.com/somearchive.tgz#mybackgroundimage.jpg); }
/style
script src=http://someplace.com/somearchive.tgz#myscript.js;
type=text/javascript/script
var img = new Image();
img.src = http://someplace.com/somearchive.tgz#myimage.png;;
Now which packaging format to use would be a discussion on it's own. An easy
route would be to use multipart/mixed that is already used for this in
e-mails and can also be gzipped using Content-Encoding.
In the context of the 3d canvas discussions, it looks like there is a
need to load binary blobs of vertex data and feed them to the graphics
card via a JavaScript call. Here is some hypothetical IDL similar to
what is being considered:
[IndexGetter, IndexSetter]
interface CanvasFloatArray {
readonly attribute unsigned long length;
};
interface CanvasRenderingContextGL {
...
typedef unsigned long GLenum;
void glBufferData(in GLenum target, in CanvasFloatArray data,
in GLenum usage);
...
};
Do you have some suggestions for how the data could be transferred
most efficiently to the glBufferData call? As far as I know there is
no tag which could be used to refer to the binary file within the
archive. If there were then presumably it could provide its contents
as a CanvasFloatArray or other type.
-Ken
On Thu, Jul 30, 2009 at 11:41 AM, Anne van Kesteren ann...@opera.com
wrote:
On Thu, 30 Jul 2009 08:49:12 +0200, Gregg Tavares g...@google.com wrote:
What are people's feelings on adding a Binary Archive API to HTML5?
I think it makes more sense to build functionality like this on top of the
File API rather than add more things into HTML5.
It seems like it would be useful if there was browser API that let you
download something like gzipped tar files.
We already have that: XMLHttpRequest.
The API would look something like
var request = createArchiveRequest();
request.open(GET, http://someplace.com/somearchive.tgz;);
request.onfileavailable = doSomethingWithEachFileAsItArrives;
request.send();
I don't think we should introduce a new HTTP API.
function doSomethingWithEachFileAsItArrives(binaryBlob) {
// Load every image in archive
if (binaryBlob.url.substr(-3) == .jpg) {
var image = new Image();
image.src = binaryBlob.toDataURL(); // or something;
...
}
// Look for a specific text file
else if (binaryBlog.url === myspecial.txt) {
// getText only works if binaryBlob is valid utf-8 text.
var text = binaryBlob.getText();
document.getElementById(content).innerHTML = text;
}
}
Having dedicated support for a subset of archiving formats in within the
API for File objects makes sense to me. Latest draft of the File API I know
of is
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
and the mailing list would be public-weba...@w3.org.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] Installed Apps
It seems the biggest concern in this discussion is around BotNet Construction Kit as Machej succulently called it, or an ability to run full-powered platform API persistently in the background, w/o a visible 'page' in some window. 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? So far, multiple ways exist to gain access to the user's machine - nearly all of them based on some dialog that asks user to make impossible decision - as bad as it is, binary downloads, plugins, browser extensions, axtivex controls or Gears modules are all but a dialog away from the user's computer. Basically, if a malicious dudes are cool to write native apps - they can have their botnet relatively easy. The ongoing fight with malware and viruses will continue - not because the platforms have wrong API, but because it's really hard to give power to the apps and not to the malware, since they, in essence, do the very similar things. As controversial as it sounds, it might be if a web platform API can't be used to write a botnet, then it can't be used to write a wide class of powerful applications as well :-) I don't have a botnet example, but when Safari 4 visits the sites in the background (to keep the 'new tab page' site snapshots up-to-date) w/o ever asking my permission - it looks a bit scary, because I'm not sure I want it to visit websites at random time from my IP with I don't know what cookies and then snapshot the result in jpg and store it locally... But I sort of like the feature anyways. Now, how can I make a web app that does this? Some sort of background shared page could be handy. It can pop up the same dialog when installed, live in Applications folder but it should be possible. Now if we make it possible, would it be possible to write a botnet on top of the API? Of course! Same exact way as it's possible to write even better botnet on OSX API in which Safari is written. Now, what if I want the same feature but implemented not as a native app, but as a web app? We would need to give it specific rights locally, and make the process transparent - not only on 'install' time but when it runs too - so the user could peek into some 'task manager' and clearly see if such thing is running. Browser could periodically download 'malware lists' and kill those web apps that are in it. But for now, it should be ok to have it 'installed' with a specific browser dialog that asks the user to make a decision the user may not understand - it is not the ideal way but it is the common way today, users know they are asked these questions, admins and IT teaches users what to do when asked, so it's the best we can do now. Having a 'task manager' (as in Chrome) reflecting those things is good too. Btw, if it only can do window.open() on the url from the same domain, then if it's from Gmail then it can't be used or hijaked. If it is from a site that says install this and I'll show you a pretty picture and user clicks through a dialog, I'd say it's not a new vector for malware. Dmitry On Thu, Jul 30, 2009 at 10:26 AM, Michael Davidson m...@google.com wrote: On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiakm...@apple.com wrote: * 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 This is an interesting idea. The lack of push updates, though, would make it much less useful than it could be. Here's a rough sketch of a more far-out idea: What if all browsers were XMPP clients and stanzas could be sent to display notifications? The attack surface would still be low, but you'd get realtime updates. Instead of subscribing to a feed of notifications, the user accepts what is essentially a chat invitation from the site. Like normal XMPP invitations, this would be revocable at any time. Lots of issues to work out, but you'd get realtime for free. Michael
Re: [whatwg] canvas paths without a current point.
Which browsers? Thanks -- dean On Thu, Jul 30, 2009 at 2:04 AM, Ian Hicksoni...@hixie.ch wrote: On Wed, 29 Jul 2009, Dean McNamee wrote: For the curves, I don't really get the point of moveTo()ing to one of the control points. Me either, but at leave for quadratic and bezier curves, that seems to be what browsers do. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Installed Apps
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? Giving web pages exactly the same power as native applications is not, and should not be, the goal. The goal is to enable many of the the same use-cases. Native apps can do anything they want and installing them is very risky. It is one of the benefits of the web that web pages you navigate to do *not* have that sort of power. Installing native apps from untrusted sources is scary. Visiting web pages should never be scary, especially since the average user stumbles upon many more web pages in a given day than native apps they would install. The desktop has no equivalent to the lightweight step of visiting a web page. Giving installed web pages (e.g. extensions) more power is much safer than silently giving all web pages that power. As controversial as it sounds, it might be if a web platform API can't be used to write a botnet, then it can't be used to write a wide class of powerful applications as well :-) I don't yet see any evidence that this is true. Certainly, enabling botnet-like power would enable a wider class of powerful applications. However, the corollary may not be true. It may be possible that we can add all the power we need to the web without enabling botnets if we are use-case driven and think of more constrained APIs that meet the same needs. Ojan I don't have a botnet example, but when Safari 4 visits the sites in the background (to keep the 'new tab page' site snapshots up-to-date) w/o ever asking my permission - it looks a bit scary, because I'm not sure I want it to visit websites at random time from my IP with I don't know what cookies and then snapshot the result in jpg and store it locally... But I sort of like the feature anyways. Now, how can I make a web app that does this? Some sort of background shared page could be handy. It can pop up the same dialog when installed, live in Applications folder but it should be possible. Now if we make it possible, would it be possible to write a botnet on top of the API? Of course! Same exact way as it's possible to write even better botnet on OSX API in which Safari is written. Now, what if I want the same feature but implemented not as a native app, but as a web app? We would need to give it specific rights locally, and make the process transparent - not only on 'install' time but when it runs too - so the user could peek into some 'task manager' and clearly see if such thing is running. Browser could periodically download 'malware lists' and kill those web apps that are in it. But for now, it should be ok to have it 'installed' with a specific browser dialog that asks the user to make a decision the user may not understand - it is not the ideal way but it is the common way today, users know they are asked these questions, admins and IT teaches users what to do when asked, so it's the best we can do now. Having a 'task manager' (as in Chrome) reflecting those things is good too. Btw, if it only can do window.open() on the url from the same domain, then if it's from Gmail then it can't be used or hijaked. If it is from a site that says install this and I'll show you a pretty picture and user clicks through a dialog, I'd say it's not a new vector for malware. Dmitry On Thu, Jul 30, 2009 at 10:26 AM, Michael Davidson m...@google.com wrote: On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiakm...@apple.com wrote: * 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 This is an interesting idea. The lack of push updates, though, would make it much less useful than it could be. Here's a rough sketch of a more far-out idea: What if all browsers were XMPP clients and stanzas could be sent to display notifications? The attack surface would still be low, but you'd get realtime updates. Instead of subscribing to a feed of notifications, the user accepts what is essentially a chat invitation from the site. Like normal XMPP invitations, this would be revocable at any time. Lots of issues to work out, but you'd get realtime for free. Michael
Re: [whatwg] Installed Apps
I think the error here is viewing this as a UX issue - if it were just a UX issue, then the responses from people would be along the lines of Oh, this sounds dangerous - make sure you wrap it with the same permissions UI that we have for extensions, plugins, and binary downloads. The realization I came to this morning is that the core of the objections are not primarily about protecting users (although this is one goal), but more about protecting the current secure web browsing model (Linus explicitly said this yesterday in his email to the list, but I only got it when thinking about it today). This is why people are OK with supporting this via extensions but not OK with supporting this as part of the core HTML APIs even if the UX was exactly the same. It's more about keeping the model pristine. Doing crazy stuff in extensions and plugins are OK because they are viewed as falling outside the model (they are just random scary things that user agents choose to do that don't conform to the specification). So arguing but it's the same UI either way! is not going to convince anyone. -atw On Thu, Jul 30, 2009 at 12:51 PM, Dmitry Titov dim...@google.com wrote: It seems the biggest concern in this discussion is around BotNet Construction Kit as Machej succulently called it, or an ability to run full-powered platform API persistently in the background, w/o a visible 'page' in some window. 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? So far, multiple ways exist to gain access to the user's machine - nearly all of them based on some dialog that asks user to make impossible decision - as bad as it is, binary downloads, plugins, browser extensions, axtivex controls or Gears modules are all but a dialog away from the user's computer. Basically, if a malicious dudes are cool to write native apps - they can have their botnet relatively easy. The ongoing fight with malware and viruses will continue - not because the platforms have wrong API, but because it's really hard to give power to the apps and not to the malware, since they, in essence, do the very similar things. As controversial as it sounds, it might be if a web platform API can't be used to write a botnet, then it can't be used to write a wide class of powerful applications as well :-) I don't have a botnet example, but when Safari 4 visits the sites in the background (to keep the 'new tab page' site snapshots up-to-date) w/o ever asking my permission - it looks a bit scary, because I'm not sure I want it to visit websites at random time from my IP with I don't know what cookies and then snapshot the result in jpg and store it locally... But I sort of like the feature anyways. Now, how can I make a web app that does this? Some sort of background shared page could be handy. It can pop up the same dialog when installed, live in Applications folder but it should be possible. Now if we make it possible, would it be possible to write a botnet on top of the API? Of course! Same exact way as it's possible to write even better botnet on OSX API in which Safari is written. Now, what if I want the same feature but implemented not as a native app, but as a web app? We would need to give it specific rights locally, and make the process transparent - not only on 'install' time but when it runs too - so the user could peek into some 'task manager' and clearly see if such thing is running. Browser could periodically download 'malware lists' and kill those web apps that are in it. But for now, it should be ok to have it 'installed' with a specific browser dialog that asks the user to make a decision the user may not understand - it is not the ideal way but it is the common way today, users know they are asked these questions, admins and IT teaches users what to do when asked, so it's the best we can do now. Having a 'task manager' (as in Chrome) reflecting those things is good too. Btw, if it only can do window.open() on the url from the same domain, then if it's from Gmail then it can't be used or hijaked. If it is from a site that says install this and I'll show you a pretty picture and user clicks through a dialog, I'd say it's not a new vector for malware. Dmitry On Thu, Jul 30, 2009 at 10:26 AM, Michael Davidson m...@google.com wrote: On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiakm...@apple.com wrote: * 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
Re: [whatwg] Dates BCE
On Thu, Jul 30, 2009 at 4:34 PM, Jim O'Donnellj...@eatyourgreens.org.uk wrote: I think Google News Timeline is worth mentioning here as an application which already does this http://newstimeline.googlelabs.com/ It shows events going back to the late Middle Ages. I'm not sure how they've harvested the dates from wikipedia. Perhaps by using microformatted dates? Probably by looking at the category markup Wikipedia uses, which is specific not only to MediaWiki but the particular decisions of the English Wikipedia editing community. time certainly wouldn't help here -- this application doesn't need a way to say this text string denotes a particular time, but rather this event happened at this particular time. You need to use Microdata or RDF or such for that kind of relationship semantics.
Re: [whatwg] Installed Apps
I think I almost get this distinction :-) you are saying that HTML+JS could be made more powerful with new APIs, but only if it is done sufficiently far from the 'regular web page browsing' experience (or model). Say, if it is a browser extension or a prism-like app it's ok - only (or mostly) because it is outside from the regular process of web browsing that users have been taught is 'reasonably safe'. Would this functionality be ok as a part of a browser extension? Lets say you can install an extension that is loaded in background (as Chrome already can do) and that the pages from the same domain are loaded into same process and can exchange DOM with it. I'm not trying to argue for the proposal, I am just curious how the more-powerful APIs could be added, since this is not the last proposal that tries to do this. Looking at use cases and coming up with narrow API that does not require permissions is understood, but it's interesting how to go beyond this line. Or, as Ojan says, if it's even a goal :-) Dmitry On Thu, Jul 30, 2009 at 1:23 PM, Drew Wilson atwil...@google.com wrote: I think the error here is viewing this as a UX issue - if it were just a UX issue, then the responses from people would be along the lines of Oh, this sounds dangerous - make sure you wrap it with the same permissions UI that we have for extensions, plugins, and binary downloads. The realization I came to this morning is that the core of the objections are not primarily about protecting users (although this is one goal), but more about protecting the current secure web browsing model (Linus explicitly said this yesterday in his email to the list, but I only got it when thinking about it today). This is why people are OK with supporting this via extensions but not OK with supporting this as part of the core HTML APIs even if the UX was exactly the same. It's more about keeping the model pristine. Doing crazy stuff in extensions and plugins are OK because they are viewed as falling outside the model (they are just random scary things that user agents choose to do that don't conform to the specification). So arguing but it's the same UI either way! is not going to convince anyone. -atw On Thu, Jul 30, 2009 at 12:51 PM, Dmitry Titov dim...@google.com wrote: It seems the biggest concern in this discussion is around BotNet Construction Kit as Machej succulently called it, or an ability to run full-powered platform API persistently in the background, w/o a visible 'page' in some window. 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? So far, multiple ways exist to gain access to the user's machine - nearly all of them based on some dialog that asks user to make impossible decision - as bad as it is, binary downloads, plugins, browser extensions, axtivex controls or Gears modules are all but a dialog away from the user's computer. Basically, if a malicious dudes are cool to write native apps - they can have their botnet relatively easy. The ongoing fight with malware and viruses will continue - not because the platforms have wrong API, but because it's really hard to give power to the apps and not to the malware, since they, in essence, do the very similar things. As controversial as it sounds, it might be if a web platform API can't be used to write a botnet, then it can't be used to write a wide class of powerful applications as well :-) I don't have a botnet example, but when Safari 4 visits the sites in the background (to keep the 'new tab page' site snapshots up-to-date) w/o ever asking my permission - it looks a bit scary, because I'm not sure I want it to visit websites at random time from my IP with I don't know what cookies and then snapshot the result in jpg and store it locally... But I sort of like the feature anyways. Now, how can I make a web app that does this? Some sort of background shared page could be handy. It can pop up the same dialog when installed, live in Applications folder but it should be possible. Now if we make it possible, would it be possible to write a botnet on top of the API? Of course! Same exact way as it's possible to write even better botnet on OSX API in which Safari is written. Now, what if I want the same feature but implemented not as a native app, but as a web app? We would need to give it specific rights locally, and make the process transparent - not only on 'install' time but when it runs too - so the user could peek into some 'task manager' and clearly see if such thing is running. Browser could periodically download 'malware lists' and kill those web apps that are in it. But for now, it should be ok to have it 'installed' with a specific browser dialog that asks the user to make a decision the user may not understand - it is not the ideal way but
Re: [whatwg] Installed Apps
On Thu, Jul 30, 2009 at 3:49 PM, Dmitry Titovdim...@google.com wrote: I think I almost get this distinction :-) you are saying that HTML+JS could be made more powerful with new APIs, but only if it is done sufficiently far from the 'regular web page browsing' experience (or model). Say, if it is a browser extension or a prism-like app it's ok - only (or mostly) because it is outside from the regular process of web browsing that users have been taught is 'reasonably safe'. Would this functionality be ok as a part of a browser extension? Lets say you can install an extension that is loaded in background (as Chrome already can do) and that the pages from the same domain are loaded into same process and can exchange DOM with it. This already exists - I mentioned previously the Firefox Jetpack extension, which is literally a hidden page that can play with the DOM of existing pages, and even includes things like jQuery and a couple of popular web service APIs (like Twitter and Gmail) for you. ~TJ
Re: [whatwg] Dates BCE
On Thu, Jul 30, 2009 at 3:45 PM, Aryeh Gregorsimetrical+...@gmail.com wrote: On Thu, Jul 30, 2009 at 4:34 PM, Jim O'Donnellj...@eatyourgreens.org.uk wrote: I think Google News Timeline is worth mentioning here as an application which already does this http://newstimeline.googlelabs.com/ It shows events going back to the late Middle Ages. I'm not sure how they've harvested the dates from wikipedia. Perhaps by using microformatted dates? Probably by looking at the category markup Wikipedia uses, which is specific not only to MediaWiki but the particular decisions of the English Wikipedia editing community. time certainly wouldn't help here -- this application doesn't need a way to say this text string denotes a particular time, but rather this event happened at this particular time. You need to use Microdata or RDF or such for that kind of relationship semantics. Nod - automated mashups of that kind are outside of the ability of time, even if extended to handle those dates. It seems that the useful things to do are: * directed mashups, where you can manually point an app at particular dates that you catch across the web and automatically slurp them. * more reliable temporal searching, at least for pages that include this kind of markup. Rather than just searching using 2000 BC or whatever and hoping that the target page includes that phrase, the search engine could also take note of manually encoded times and use these to help filter the returned results ~TJ
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Jul 30, 2009, at 10:18 AM, Michael Davidson wrote: On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiakm...@apple.com wrote: Here's some security risks I've thought about, for persistent workers and persistent background pages: great list of risks Thanks for the list, Maciej. However, Firefox extensions today have all of the same problems. Do you consider the permission UI in Firefox insufficient? Given Safari's extension model, I'm going to guess the answer is yes. The fact that FF has extensions, however, at least shows that one browser vendor believes that sufficient permission UI exists. I'm not sure if I'd be totally comfortable with putting something as streamlined as the Firefox extensions model. As presented on http://addons.mozilla.org/ , it seems fine - the extensions posted there are centrally vetted and reviewed, the user has to take a clear explicit step to start the install, and there is a revocation model. But the fact that third party pages can trigger automated extension install seems problematic. For example, just visiting http://gears.google.com/download.html in Firefox, I am immediately faced with an alert dialog where the default button will install native code that runs in my browser. If any page can do that, then browsing with Firefox puts you one enter keystroke away from running native code (well, once Firefox restarts, anyway). I'm not really sure why Mozilla thinks that is ok. Regards, Maciej
Re: [whatwg] Dates BCE
2009/7/30 Aryeh Gregor simetrical+...@gmail.com time certainly wouldn't help here -- this application doesn't need a way to say this text string denotes a particular time, but rather this event happened at this particular time. The latter presupposes the former. That's why being able to mark historical dates up with time or date or year (etc, as appropriate) would be so useful, and indeed appropriate in HTML5.
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
Maciej Stachowiak wrote: I'm not sure if I'd be totally comfortable with putting something as streamlined as the Firefox extensions model. As presented on http://addons.mozilla.org/, it seems fine - the extensions posted there are centrally vetted and reviewed, the user has to take a clear explicit step to start the install, and there is a revocation model. But the fact that third party pages can trigger automated extension install seems problematic. For example, just visiting http://gears.google.com/download.html in Firefox, I am immediately faced with an alert dialog where the default button will install native code that runs in my browser. That particular page does so by loading https://addons.mozilla.org/google/google_gears_linux.html (or the equivalent for mac and Windows) in an iframe. So this is treated just like any extension install from addons.mozilla.org by the browser. If you try doing an install of an XPI that's not on a site on the extension install whitelist, all that happens is a notification bar that says something like: Firefox prevented this site (foo.com) from asking you to install software on your computer. and has an Allow button if the user wants to allow the install. If you click that button, then you get the dialog you see on the gears page. None of this adds the site to the whitelist, so if you go to install another extension from the same site again you have to explicitly allow it again. If any page can do that, then browsing with Firefox puts you one enter keystroke away from running native code (well, once Firefox restarts, anyway). I'm not really sure why Mozilla thinks that is ok. I hope the above helps. -Boris
Re: [whatwg] Installed Apps
So use an out-of-band extension mechanism to establish trust and permissioning for capabilities that fall out of bounds of the 'regular' web model. So lets put that to practice on this particular two-part proposal... Our proposed solution has two parts. This first part (below) falls within the bounds of the 'regular' web model. Would be nice to discuss this on the merits in absense of the 'scary trust permissioning' issues. The first, which should be generally useful, is the ability to have a hidden HTML/JS page running in the background that can access the DOM of visible windows. This page should be accessible from windows that the user navigates to. We call this background Javascript window a shared context or a background page. This will enable multiple instances of a web app (e.g. tearoff windows in Gmail) to cleanly access the same user state no matter which windows are open. This second part (below) would only be accessible after out-of-band trust and permissioning mechansims got tickled. Additionally, we'd like this background page to continue to run after the user has navigated away from the site, and preferably after the user has closed the browser. This will enable us to keep client-side data up-to-date on the user's machine. It will also enable us to download JS in advance. When the user navigates to a web app, all the background page has to do is draw the DOM in the visible window. This should significantly speed up app startup. Additionally, when something happens that requires notification, the background page can launch a visible page with a notification (or use other rich APIs for showing notifications). (aside... begs the question... when will that extension mechanism be standardized :) On Thu, Jul 30, 2009 at 1:49 PM, Dmitry Titov dim...@google.com wrote: I think I almost get this distinction :-) you are saying that HTML+JS could be made more powerful with new APIs, but only if it is done sufficiently far from the 'regular web page browsing' experience (or model). Say, if it is a browser extension or a prism-like app it's ok - only (or mostly) because it is outside from the regular process of web browsing that users have been taught is 'reasonably safe'. Would this functionality be ok as a part of a browser extension? Lets say you can install an extension that is loaded in background (as Chrome already can do) and that the pages from the same domain are loaded into same process and can exchange DOM with it. I'm not trying to argue for the proposal, I am just curious how the more-powerful APIs could be added, since this is not the last proposal that tries to do this. Looking at use cases and coming up with narrow API that does not require permissions is understood, but it's interesting how to go beyond this line. Or, as Ojan says, if it's even a goal :-) Dmitry On Thu, Jul 30, 2009 at 1:23 PM, Drew Wilson atwil...@google.com wrote: I think the error here is viewing this as a UX issue - if it were just a UX issue, then the responses from people would be along the lines of Oh, this sounds dangerous - make sure you wrap it with the same permissions UI that we have for extensions, plugins, and binary downloads. The realization I came to this morning is that the core of the objections are not primarily about protecting users (although this is one goal), but more about protecting the current secure web browsing model (Linus explicitly said this yesterday in his email to the list, but I only got it when thinking about it today). This is why people are OK with supporting this via extensions but not OK with supporting this as part of the core HTML APIs even if the UX was exactly the same. It's more about keeping the model pristine. Doing crazy stuff in extensions and plugins are OK because they are viewed as falling outside the model (they are just random scary things that user agents choose to do that don't conform to the specification). So arguing but it's the same UI either way! is not going to convince anyone. -atw On Thu, Jul 30, 2009 at 12:51 PM, Dmitry Titov dim...@google.com wrote: It seems the biggest concern in this discussion is around BotNet Construction Kit as Machej succulently called it, or an ability to run full-powered platform API persistently in the background, w/o a visible 'page' in some window. 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? So far, multiple ways exist to gain access to the user's machine - nearly all of them based on some dialog that asks user to make impossible decision - as bad as it is, binary downloads, plugins, browser extensions, axtivex controls or Gears modules are all but a dialog away from the user's computer. Basically, if a malicious dudes are cool to write native apps - they can have
Re: [whatwg] Installed Apps
2009/7/29 Maciej Stachowiak m...@apple.com On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote: Hello folks - I'm an engineer on the Gmail team. We've been working on a prototype with the Chrome team to make the Gmail experience better. We thought we'd throw out our ideas to the list to get some feedback. THE PROBLEM We would like to enable rich internet applications to achieve feature parity with desktop applications. I will use Gmail and Outlook as examples for stating the problems we hope to solve. I already commented on the security risks of the proposed solution, but I'd also like to examine the use cases more closely. Feature parity with desktop applications is pretty open-ended, and it might be that the actual concrete use cases can be addressed with less general mechanisms. -- Slow startup: When a user navigates to mail.google.com, multiple server requests are required to render the page. The Javascript is cacheable, but personal data (e.g. the list of emails to show) is not. New releases of Gmail that require JS downloads are even slower to load. Caching the code part of GMail, and making loading fast in the face of updates, seems like a problem that can be solved by the HTML5 Application Cache. Maybe it would be more fruitful to study further improvements in startup speed once GMail has adopted AppCache. -- Native apps like Outlook can (and do) run background processes on the user's machine to make sure that data is always up-to-date. -- Notifications: Likewise, Outlook can notify users (via a background process) when new mail comes in even if it's not running. I'm not sure it's justifiable to say these features are required for a native-like experience. The Mail application on Mac OS X only fetches new mail and gives you new mail notifications while it is actually running. Users who want to know about new mail right away keep the app open, and users who would like to free up resources quit it. It seems like GMail can already get rough parity with this experience. Depends on the device. If you're on Android (or I suspect iPhone, although I don't have one), doesn't the device sync your email constantly in the background? If I am a web-based email provider, I would like to have a similar option. Especially on something like the iPhone or Android, where I don't think it's reasonable to expect them to keep the browser open all the time (as the browser will just get closed if some other active app applies memory pressure). 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.
Re: [whatwg] Dates BCE
David Singer wrote: Against that, one has to realize that the label of the day before X is well-defined for the day before the introduction of the Gregorian calendar, and iteratively going back to year 1, year 0, year -1, and so on. In neither the Gregorian nor the Julian calendars is there a year 0, as used in conventional speech (formats designed for machine computation treat the issue a little differently). -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] canvas paths without a current point.
On Thu, 30 Jul 2009, Dean McNamee wrote: Which browsers? I was testing primarily Opera, Firefox, and Safari. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fwd: Entity parsing
On Sat, 18 Jul 2009, �istein E. Andersen wrote: Non-semicolon-terminated entities that were conforming in HTML4, like pi and mdash when they are not followed by a letter or digit (roughly speaking), are currently expanded in Safari and Firefox, and requiring this to change would be a regression affecting existing pages. As far as I can tell HTML5 more or less matches what legacy pages need, You keep repeating this, and also that much work has been done to get entity parsing right and that you really do not want to change it. It seems to me that you have tried to follow IE's behaviour closely, which is not completely unreasonable. I have not seen evidence of any analysis of legacy pages supporting this decision, though; on the contrary, more or less anecdotal evidence sent to the mailing list(s) seems to suggest that certain modifications might make the algorithm work better for legacy pages. Replicating IE may well be good enough and seems like a reasonably safe option, but HTML5 does not completely follow IE in other areas, and I do not quite see why entity parsing should be treated differently. It's certainly the case that we can find individual pages that depend on particular behaviours to support any argument. I do not want to change the current parsing spec unless we have _very_ good reasons to do so, because there are now multiple implementations and tests, and any change can introduce bugs and incompatibilities. If you have strong data showing that a particular change to the spec would be highly beneficial, then it's something I'd be happy to consider. But I'm not willing to make changes just to change the spec from being compatible with IE to being compatible with WebKit, or some such. I need data showing that the change is needed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The StyleSheet object (section 4.2.7)
On Sat, 18 Jul 2009, Alex Bishop wrote: There's a few parts of the specification of the StyleSheet object defined in section 4.2.7 that are unclear to me. The location (href DOM attribute) For link elements, the location must be the result of resolving the URL given by the element's href content attribute, relative to the element, or the empty string if that fails. For style elements, there is no location. If there is no location, does that mean the attribute is null? Should that be explicitly stated? CSSOM says it must return null for embedded styles: http://dev.w3.org/csswg/cssom/#style-sheet-location The intended destination media for style information (media DOM attribute) The media must be the same as the value of the element's media content attribute. If the element's media content attribute is omitted, what should the value of the attribute be? Should it be all (which section 4.2.6 defines as the default if the media content attribute is omitted)? Null? The empty string (à la DOM reflection)? Fixed. In any case, the definition above seems to conflict with the definition of the media attribute in the CSS Object Model specification at http://dev.w3.org/csswg/cssom/#stylesheet, which requires that the attribute returns a MediaList. I've fixed the section in HTML5 to not override the CSSOM spec, but instead to just use the hooks defined in CSSOM (except for the disabled flag, which seems to be an error -- it seems like that one should just be initialised by the stuff we define for alternative style sheets.) The style sheet title (title DOM attribute) The title must be the same as the value of the element's title content attribute, if the attribute is present and has a non-empty value. If the attribute is absent or its value is the empty string, then the style sheet does not have a title. The title is used for defining alternative style sheet sets. Again, if there is no title, does that mean the attribute is null? This is defined by CSSOM, but I've tried to make HTML5 clearer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] cross-domain scrollIntoView on frames and iframes
On Sat, 18 Jul 2009, Adam Barth wrote: On Fri, Jul 17, 2009 at 4:10 PM, Ian Hicksoni...@hixie.ch wrote: Suppose that there is a tool where someone can write some text, in which case the text will be displayed when the page is loaded. Suppose that whether the person has written this text is confidential, and that whether one had entered text there or not would reveal something that the user would prefer to keep secret. You could use this API to tell whether or not another user had entered text, by opening an iframe to that page, and then trying to scroll from distance n to distance n+10 many times in a loop, and timing how long it takes to do the scroll. If there is no more content in the page, then scrolling to n and n+10 would take less time than it would if there was more content (since scrolling is slower than doing nothing). I suspect you could extract that information more easily by just timing the page load: http://crypto.stanford.edu/~abortz/papers/timingweb.pdf Yes, that would be another way of getting this information. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] do not encourage use of small element for legal text
On Sun, 19 Jul 2009, Eduard Pascual wrote: On Sun, Jul 19, 2009 at 12:29 PM, Ian Hickson i...@hixie.ch wrote: [...] On Fri, 3 Jul 2009, Eduard Pascual wrote: It's clear that, despite the spec would currently encourage this example's markup, it is not a good choice. IMHO, either of these should be used instead: pYour 100% satisfaction in the work of SmallCo is guaranteed. (Guarantee applies only to commercial buildings.)/p or smallYour 100% satisfaction in the work of SmallCo is guaranteed. (Guarantee applies only to commercial buildings.)/small In practice, if the author wants to make the parenthetical text smaller, he will. The question is whether we should encourage such small text to be marked up in a way distinguishable from other stylistic spans. Indeed, making legal text clearly readable should be a goal. However, I don't think it is too much a HTML5 goal: afaik, in most countries there are general laws that define which kind of text can hold legal value on different kinds of media, dealing with details such as minimum size and color contrasts for each media, maximum speed for running text (like bottom-screen text on TV ads), and so on. Of course, these will vary from country to country and/or region to region; but IMHO general law is the area where legal text should be handled with. Authors hence should find advice about the actual requirements for legal text to be legally binding (ie: asking their lawyers for advice), and honor such restrictions when putting a webpage together. It is pointless to make specific encouragements or discouragements on how to include legal text on an HTML5 document: a good advice may backfire if it leads a good-intended author to do something that doesn't match local laws on that regard; and evil-intended users will ignore any advice from the spec and just push as much as they can to the edge, looking for the most hard-to-read-but-still-legal possible form. The basic task of HTML (the language itself, not the spec defining it) is to provide authors with tools to build their documents and pages in an interoperable way. HTML5 does well that job in the area of small print, providing the small element to mark it up. That's exactly enough, and IMHO there is no point on trying to go further. The spec now has no encouragements at all. This is all it says: # The small element represents small print or other side comments. It then has two non-normative comments: # Small print is typically legalese describing disclaimers, caveats, legal # restrictions, or copyrights. Small print is also sometimes used for # attribution. # # The small element does not de-emphasize or lower the importance of # text emphasized by the em element or marked as important with the strong # element. This is about as neutral as I can make it while still keeping it useful. I'm not sure if the word legalese was intended to refer to all kinds of legal text, or just the suspicios or useless ones. In any case, a more accurate wording would help. This wording is vague intentionally, because it is a vague observation. I don't know how we could make it more accurate. If vagueness is intentional, just take thing explicitly vague, rather than a term that some may just take as vague but others may take as catch-all and others seem to even find offensive/despective. I really don't understand this objection. First, leave the formal description The small element represents small print or other side comments. as is: IMHO it is accurate and simple, and that's quite enough to ask from a spec. Next, replace the note that reads Small print is typically legalese describing disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution. with something like this: Small print is often used for *some* forms of legal text and for attribution. [...] This makes clear that HTML (technically) allows using small to put legal text (or anything else) in small print, but it doesn't encourage any specific usage of small print. I'm not convinced the suggested text is any better than the current text, to be honest. [...] [...] The key on the sentence Small print is often used for *some* forms of legal text and for attribution. is the emphasis on some: this should be enough for any reader to understand that, if only some forms go on small print, other forms just don't. The some achieves your intended vagueness, and the emphasis makes such vagueness explicit enough. The current wording small print is typically used for legalesse is not just vague, but as ambiguous as the term legalesse itself: a significant proportion of authors might miss-understand it and assume that any form of legal text is legalesse, so it can be on small print, but it isn't require to be so (because of the typically). Addressing this potential
Re: [whatwg] Installed Apps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/30/09 7:26 PM, Michael Davidson wrote: On Wed, Jul 29, 2009 at 5:38 PM, Maciej Stachowiakm...@apple.com wrote: * 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 This is an interesting idea. The lack of push updates, though, would make it much less useful than it could be. Here's a rough sketch of a more far-out idea: What if all browsers were XMPP clients and stanzas could be sent to display notifications? The attack surface would still be low, but you'd get realtime updates. Instead of subscribing to a feed of notifications, the user accepts what is essentially a chat invitation from the site. Like normal XMPP invitations, this would be revocable at any time. Lots of issues to work out, but you'd get realtime for free. We're working on that over in the XMPP community... :) Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpyMTMACgkQNL8k5A2w/vwKNgCg+8q/BEv4jZzKbhMZ7Vz6pDFR iygAnjUJGy0Sn/hA4iTxrX46W6A5VGuf =qetP -END PGP SIGNATURE-
Re: [whatwg] Rel and META values
On Tue, 21 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/19/2009 5:39 AM: On Wed, 15 Jul 2009, Bil Corry wrote: I'm curious too, since the HTML5 draft itself says[1]: - This specification does not define how new values will get approved. It is expected that the Wiki will have a community that addresses this. - So the verbiage at the bottom regarding how a status becomes Accepted appears to be incorrect. There is no process currently in place to adopt any proposed rel value as Accepted. The community right now is defined as the microformats+w3c communities. I'd like a more dedicated community, but that doesn't just happen on its own -- someone has to step forward and own that process. It's a lot of work, and if we are to have continuity and stability in the process, it would have to be someone willing to commit to this for many years. What do you think of adopting Web Linking's registry and registration process? http://tools.ietf.org/html/draft-nottingham-http-link-header-06#section-6.2 Sounds way more complex than a wiki! I've sent last call comments to that effect. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] autobuffer on new Audio objects
On Mon, 20 Jul 2009, David Wilson wrote: 2009/7/19 Ian Hickson i...@hixie.ch: On Mon, 6 Jul 2009, Robert O'Callahan wrote: When script creates an audio element using the new Audio constructor, the 'autobuffer' attribute should be automatically set on that element. Presumably scripts will only create audio elements that they actually intend to play. Done. This seems like surprising behaviour (and a nasty asymmetry between markup and JS): for the savings of a single line of code, creating a new element will automatically result in (high bandwidth) network IO. Only if the user agent honours the autobuffer attribute. It doesn't have to. I don't think the intent of creating Audio instances clearly always means playback will happen. What other use cases do you have in mind? It's easy to see how some naively implemented JS audio widget could fetch 200mb over an expensive 3G connection, simply by navigating to some site in a background tab (say, by creating an array of elements to represent their playlist - something I'd have thought was perfectly valid behaviour). A mobile phone would not autobuffer in a background tab. On Mon, 20 Jul 2009, Nils Dagsson Moskopp wrote: I second that motion, not only as owner of a smartphone, but also as someone with webspace that has a volume cap. Automagic audio element buffering could deter web authors from dynamically putting more than one element on a page, thus reserving javascript playlist widgets to those who can afford more bandwith on an order of magnitude (!). This doesn't apply to elements on the page, only to script-created elements. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 Definition of week (section 2.4.5.6)
On Mon, 20 Jul 2009, David Singer wrote: At 10:45 + 19/07/09, Ian Hickson wrote: On Fri, 3 Jul 2009, SJ Kissane wrote: I am concerned by the wording of this section. There are different systems of week number -- as far as I can work out, this is the same as ISO 8601 week numbering. But it nowhere explicitly says that. I think, the spec should have a normative reference to ISO 8601 for the definition of week numbering. Then, if the spec wants to give an informative recap of what ISO 8601 says, for the benefit of those who don't have a copy (especially since it isn't free), that's fine. But I'm worried, by inserting some complicated definition into the spec, does it match exactly ISO 8601's definition? (I'm sure it does, but are the definitions the same? is not immediately obvious from inspection.) They are not the same. ISO8601 doesn't define how you parse a week string, how you handle errors in such a string, and so forth. The numbers are compatible, and a valid HTML5 week string is an ISO8601 week string (though I don't know if the opposite is the case), but that's about it. While we could have an non-normative reference, in practice, it wouldn't add much, since (a) the HTML5 spec defines everything you might get from ISO8601, and (b) we don't want to have implementors think oh, it's the same as ISO8601, I'll just use an ISO8601 date library, since such a library might get the parsing details wrong in terms of what HTML5 says. an informative note to that effect might be a good idea. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Re Validation
On Mon, 20 Jul 2009 dar...@chaosreigns.com wrote: Why is it okay for a document to not specify its HTML version? That's the wrong question -- the more important question is why should we specify the version of HTML that the author knew about when he started writing the document?. Do all browsers ignore it? Yes. How should a validator handle lack of HTML version info when the next standard is released with no DOCTYPE? A validator should always check against the most recent standard, unless the user has explicitly requested some other profile. Should validators ignore older HTML version numbers which are listed in DOCTYPES? They should warn about old DOCTYPEs and show errors for unknown ones. Why aren't MIME type version numbers included in HTTP Accept headers? What good would it do? On Mon, 20 Jul 2009 dar...@chaosreigns.com wrote: Say I have some pages on my site that are HTML7, because I know that IE 10 has pretty good support for it. And I have some other pages that are in HTML9 which became a Recommendation 4 years ago but which which IE 10 still doesn't support, but I have been very careful to accommodate IE 10 users by various means. And I want to use a spidering validator on my entire site. And I want to make sure that the HTML7 stuff is valid HTML7 so I can mostly not worry about it working with IE 10, but the HTML9 pages obviously wouldn't validate as HTML7. Just tell your spider that you want your pages checked for compatibility with IE10. It seems to me that in this case having an HTML version number somewhere in the document would be useful. And that this is a practical example. The HTML version number has little bearing on whether the browsers support it. For example, IE8 supports some things from HTML5 and doesn't support everything from HTML4. On Tue, 21 Jul 2009 dar...@chaosreigns.com wrote: Am I correct in concluding that my best option is to create my own HTML5 DTD, and use a DOCTYPE along the lines of: !DOCTYPE html SYSTEM http://www.chaosreigns.com/DTD/html5.dtd; ? That would be invalid in HTML5. It's not clear what you're trying to do. I doubt a DOCTYPE or DTD is the best way to solve your problem, though, whatever it is. Can the HTML5 spec be modified slightly to say that this sort of thing complies? ( http://dev.w3.org/html5/spec/Overview.html#the-doctype ) No, because it would encourage people to do what you're thinking of doing, which is a bad idea. :-) Another use that occurred to me is the case where someone has thousands of html files, which they want to automatically validate at once, and some of them have been updated to a more recent standard (and they want to make sure they stay compliant with it), but others have not been dealt with yet. If for some reason you wanted to check some pages against HTML4 instead of HTML5, you could do that today just by noting which pages you want tested against the older version, either in some file, or by putting some comment in the file, or something. You don't need any help from HTML itself to do this. For example: On Tue, 21 Jul 2009, Tab Atkins Jr. wrote: If you absolutely need to embed extra information (such as a validation schema that you will use for your own purposes to validate your own documents), there are a multitude of ways to do so. You could use a data-* attribute on the html element. You could use Microdata to encode the information onto the document. You could use a link element to point to the schema. But I don't know why you would ever want to do that. It seems to me that the best thing would be to use a tool that just tells you which browsers a page is compatible with, and whether it follows the latest standards. You could then set off the spider on all pages on the site, and get back a report that says: The following pages don't work in IE12: ... The following pages have validation problems: ... ...etc. No need for the _pages_ to say which browsers they want to be compatible with; you presumably always want to be compatible with as many browsers as possible. If you actually care about compliance to older versions of HTML, then: On Mon, 20 Jul 2009, Aryeh Gregor wrote: So have the validator say This is valid HTML7 or This is valid HTML9 or This is valid HTML7, HTML8, and HTML9 or whatever is applicable. It can check all the standards at once. Why does it need to check only one? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=tel validation, and a small set of typos
On Mon, 20 Jul 2009, Peter Kasting wrote: Two unrelated comments. First, it seems a bit odd to me that input type=email and input type=url are validated (for typeMismatch problems) but input type=tel isn't. I know it's prohibitively difficult to perfectly validate telephone number formats given the variety around the world, but it's also prohibitively difficult to validate email addresses per the relevant RFC, which is why HTML5 specs a much simpler algorithm that at least rejects obviously bad input. This was originally considered, but in practice, telephone number fields are generally free-form fields that are interpreted by humans, unlike URI and e-mail values, which tend to be treated as opaque strings by humans and just handled purely by code. (I carefully studied a number of telephone input UIs before making that particular design decision.) Second comment: There are 4 instances of a small typo in attribute lists, where ..., required, size, ... is rendered as ..., required size, Fixed. On Mon, 20 Jul 2009, Nils Dagsson Moskopp wrote: What's with alphanumeric notation ? I think of 555-WHATWG as a possibly valid telephone number. It might be good to have an RFC on that. Or maybe ITU has publicly available documents on numbering plans ? The ITU does have some documents, but they weren't that useful (I studied them when writing the tel spec originally). On Mon, 20 Jul 2009, Peter Kasting wrote: Yeah, I thought of that kind of thing (but didn't mention it). If we don't want to disallow users from doing things like this, there probably isn't a simple enough validation algorithm we can use. It might be nice to mention in the spec why type=tel is not validated the way email and url are, at that point. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Stripping newlines from URI attributes
On Wed, Jul 29, 2009 at 6:49 PM, Kartikaya Gupta lists.wha...@stakface.comwrote: This behavior doesn't seem to be specced anywhere as far as I can tell. Assuming the WEBADDRESSES spec referred to in HTML5 is the one at http://www.w3.org/html/wg/href/draft.html that only says to trim leading/trailing whitespace and url-encode the rest. This doesn't seem to match existing behavior, so it should probably be updated. RFC 3986, which is referenced in the Web addresses specification, states In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have to be added to break a long URI across lines. The whitespace should be ignored when the URI is extracted. Firefox's behavior appears to be consistent with this. -Alex
[whatwg] DOMTokenList feedback
On Mon, 20 Jul 2009, Sylvain Pasche wrote: 1) What's the reason for preserving whitespace when a DOMTokenList method is changing the attribute? As a general rule, I try to make the APIs as minimally invasive as possible. Whenever we have failed to do this, we end up confusing authors -- for example, look at the confusion that has been cause by the .style attribute reserisalising the underlying CSS instead of just preserving it. 2) If preserving whitespace is not important, what about normalizing whitespace during mutation? By normalizing whitespace, I mean splitting tokens (keeping unique ones), doing the DOMTokenList add/remove/toggle operation, and joining tokens together separated by a whitespace. If you pre-split the tokens, I guess you could keep pointers into the underlying string around to make editing the string faster. In general, though, these strings are so short, that I'd expect this to more or less be a wash either way. On Wed, 22 Jul 2009, Anne van Kesteren wrote: On Mon, 13 Jul 2009 05:16:19 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 15 Jun 2009, Adam Roben wrote: Should methods of element.classList treat their arguments case-insensitively in quirks mode? I think they should. This should be mentioned in the spec. I've clarified that DOMTokenList is always case-sensitive. We don't want to be adding more quirk-mode behaviours. Using quirks mode is not conforming (i.e. it's not a supported behaviour). Implementation-wise that does not seem nice if you want to use the same optimized object when dealing with style sheets or getElementsByClassName(). Alternatively we could require I suppose that in quirks mode class names are normalized to be lowercase or some such and keep getElementsByClassName() and classList case-sensitive... I don't follow. Which object are you going to reuse? On Mon, 27 Jul 2009, Jonas Sicking wrote: It's certainly doable to do this at the time when the token-list is parsed. However given how extremely rare duplicated classnames are (I can't recall ever seeing it in a real page), I think any code spent on dealing with it is a waste. Yeah. On Tue, 28 Jul 2009, Sylvain Pasche wrote: Jonas: The remove() algorithm is about 50 lines with whitespace and comments. After all, that's not a big cost and I guess that preserving whitespace may be closer to what DOMTokenList API consumers would expect. The code would be 7 lines if we didn't need to preserve whitespace: nsAttrValue newAttr(aAttr); newAttr-ResetMiscAtomOrString(); nsCOMPtrnsIAtom atom = do_GetAtom(aToken); while (newAttr-GetAtomArrayValue().RemoveElement(atom)); nsAutoString newValue; newAttr.ToString(newValue); mElement-SetAttr(...); If you spent a few more lines of code you could even avoid serializing the token-list and call SetAttrAndNotify instead of SetAttr. That's an interesting comparison. Less code and much more readable than my remove() implementation I have to say. I'm somewhat reluctant to make the DOMTokenList API destructive. 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. (We're agreed that removing would remove all duplicates, and that the order would be preserved, right?) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A
Re: [whatwg] Driveby typo notice
On Mon, 20 Jul 2009, Jeff Walden wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource When the user agent has completely fetched of the entire media resource s/ of// Fixed, thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Driveby typo notice
On Tue, 21 Jul 2009, Remco wrote: On Tue, Jul 21, 2009 at 6:27 AM, Jeff Waldenjwalden+wha...@mit.edu wrote: http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource When the user agent has completely fetched of the entire media resource s/ of// Also, completely and entire do the same thing. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] autobuffer on new Audio objects
Am Freitag, den 31.07.2009, 00:26 + schrieb Ian Hickson: On Mon, 20 Jul 2009, Nils Dagsson Moskopp wrote: I second that motion, not only as owner of a smartphone, but also as someone with webspace that has a volume cap. Automagic audio element buffering could deter web authors from dynamically putting more than one element on a page, thus reserving javascript playlist widgets to those who can afford more bandwith on an order of magnitude (!). This doesn't apply to elements on the page, only to script-created elements. I was referring to exactly that. Creating an audio element for every audible file in a directory isn't something one would necessarily do on the server side. But as long as there is a possibility to not trigger buffering when creating media objects, all may be well. Cheers, -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
[whatwg] Progress on video accessibility
Hi, Several proposals have been made on this list in the past on how to approach accessibility for the HTML5 video element. I think the best way in which we can progress this is by doing an implementation of a spec, discussing it, improving the spec, rinse and repeat, which IIUC is the process WHATWG is using anyway. So, in this spirit, I would like to contribute a specification and implementation for how to attach out-of-band time-aligned text data to HTML5 video (and audio) elements. What I mean by out-of-band is that the text that is associated with the video is not available inside the binary video stream, but as a separate Web resource and needs to be retrieved before it can be displayed. This is a common use case and should be supported from within HTML5 in addition to supporting in-band time-aligned text. BTW: in-band time-aligned text for Ogg is something I want to experiment with next, since I would like us to get to an API that supports both, in-band and out-of-band, in the same way. But let me get straight to this current experiment: - the demo is at http://www.annodex.net/~silvia/itext/ . - the specification is at https://wiki.mozilla.org/Accessibility/HTML5_captions - a description and a first set of feedback that I have gathered is at https://wiki.mozilla.org/Accessibility/Experiment1_feedback Let me list some of the thoughts behind the proposal: * I can see a need for a multitude of different categories of time-aligned text that either already exist or will be developed in the future. The list that I can currently grasp is mentioned in the specification. While these text categories are rather diverse (e.g. karaoke text, ticker text, chapter markers, captions), they all share common properties and can be handled in fundamentally the same way by a browser. I therefore propose a common itext element (for included text) to deal with associating such time-aligned text resources with video resources. * While the demo only shows how to apply itext to video, I believe it should be possible to also associate all of them with audio. An implementation experiment is necessary to examine the differences, which I believe to be mostly about display mechanisms. * I can also see a need for internationalisation of each text category. I.e. each text resource will come with an associated language for which it is valid and alternative language resources will be made available. This is why I am suggesting the @lang attribute. * Together, the @category and @lang attributes create a list of text tracks for the video for different display mechanisms. Assuming differing @lang tracks of the same @category are alternatives, while all @category tracks are allowed to appear at the same time, I developed a DVD-like menu for time-aligned text. You will find it in the demo under the text bubble button. * It is unclear, which of the given alternative text tracks in different languages should be displayed by default when loading an itext resource. A @default attribute has been added to the itext elements to allow for the Web content author to tell the browser which itext tracks he/she expects to be displayed by default. If the Web author does not specify such tracks, the display depends on the user agent (UA - generally the Web browser): for accessibility reasons, there should be a field that allows users to always turn display of certain itext categories on. Further, the UA is set to a default language and it is this default language that should be used to select which itext track should be displayed. * Since there is not a single file format that satisfies all categories of time-aligned text, I can see a need for itext to allow it to link to several different text formats. The only one used in the demo is SRT. I will also be looking at LRC and DFXP. I believe ultimately we will want to state which format a browser must support as baseline, but I also believe we need to experiment with them a bit more. I am not intending to define another new format at this stage. However, I have added a @type attribute to itext so we can specify which file format is to be expected at the end of the @src link. This is similar to the @type attribute of the video element. * Several of the current de-fact standard formats of time-aligned text are rather simple (including SRT and LRC) and do not include information about the charset that they are encoded in. For that reason, a @charset attribute was added to the itext specification. * Another typical feature of time-aligned text files is that they may be out of sync with the actual video file. For that purpose, a @delay attribute was suggested as an addition to the itext element. This has not been implemented into the demo. In the feedback to this proposal, a further stretch or drift attribute was suggested. * The idea for the display of the text categories is that we use existing browser display capabilities to do the display. Thus, I have defined for each text category
