[whatwg] Undefined spec about removing node in a range.
Suppose following DOM tree: div0 - div1 - div2 - - div3 - div4 - - div5 In addition, range is of start at (div2,0) and end at (div4, 0). What will happen when we delete a node div2? http://dom.spec.whatwg.org/#node-is-removed When we are going to delete a node, current spec says cases that a range boundary point is a descendant of the node or a parent of the node. However it is undefined when a boundary point is the node. I guess the case 2 and 3 should be: 2. For each range whose start node is a inclusive descendant of node, set its start to (parent, index). 3. For each range whose end node is a inclusive descendant of node, set its end to (parent, index).
Re: [whatwg] Notifications improvements
On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo bever...@google.com wrote: Hi Andrew, On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson atwil...@google.com wrote: On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com wrote: I understand your concern that is driving this proposal: you don't want to provide rich APIs that can't be well implemented on every platform, and thereby fragment the web platform. I just don't want to see us go down this path of adding these new notification types that are so limited in ability that people will just keep using general notifications anyway - I'd rather just stick with the existing API. Are you unenthusiastic about any of the proposed additions (what about those already added?) or is this more about the more complex features such as indication of progress? I'm (somewhat) unenthusiastic about the new semantic types, because I'm not sure they'd get enough uptake to be worth the effort to implement (note that this is just my personal opinion - I'm no longer as heavily involved in the notification work within Chromium, so Peter B's opinion carries much more weight than mine when it comes to determining what we'd implement). I find myself being in favor of the semantic types. The primary reason for this is that it allows us to provide a much more consistent user experience, especially on platforms where we don't control rendering of the notification, compared to HTML notifications. On Chrome for Android we want to provide for a consistent user experience, where notifications should be visually indistinguishable (aside from clarifying the origin) from those created by native apps. The proposed semantic types would get us there. Furthermore, support for HTML notifications will be much more difficult to implement across the board. Some mobile OSes, notably Firefox OS and iOS, wouldn't support this at all. Others, such as Android, theoretically could support it, but won't because it means creating an entire WebView -- causing very significant memory pressure on already resource constrained devices. To be clear, I'm not arguing for HTML notifications - as I said in my original post to this thread, HTML notifications were removed from the spec for various good reasons. But I think it's a mistake to just bake in canned notification types. What if a developer wants a progress bar with a cancel button? A progress bar with a timestamp? A list notification that contains an event with timestamp? Or some other different notification that doesn't specifically match one of your curated templates, but could easily be built if you gave him a lower-level set of primitives? Implementation wise, Chrome recently switched to rendering Notifications using a new message center implementation, which already supports rich data such as progress bars, timestamps, lists and buttons. On Android many of these features will come down to calling an extra method on the Java Notification.Builder. I am quite enthusiastic about adding support in the API around allowing users to interact with notifications after the parent page has closed, however. Having a new field timestamp that carries a particular point in time related to the message seems quite useful for instance and not very intrusive. Perhaps I'm not understanding how this would be used. What would such a notification look like for (say) a calendar event (Your 1PM meeting starts in 5 minutes) versus a countdown timer (In 73 seconds, your hard boiled egg will be done cooking)? Would we have to provide a format string so the UA knows where to inject the time remaining, or would it always have to be put at the end? Do we need to specify granularity of updates (i.e. if I have a stopwatch app, I probably want to update every second, but for a calendar app, updating every 5 minutes is probably sufficient, until we get down to the last 5 minutes)? I would argue that this is a feature that should be defined by the UA or platform. I'm not sure whether using a counting notification is the right way to implement a count-down -- I would expect normal, foreground UI displaying a counter, and a notification if that UI was moved to the background and the counter expired. The timestamp doesn't necessarily need to be in the future either. At least for me, a calendar notification that is constantly updating its countdown every minute but has no snooze functionality is actually a mis-feature, because it's distracting. The notification wouldn't visually re-announce itself on every update. Again, I don't want to be overly negative about this - maybe there are use cases like list notifications where the new API would be really useful, but as soon as I start thinking about more complex display scenarios, I immediately want to start having more control over the formatting of the text
Re: [whatwg] resource hints and separating download from processing
On Thu, 7 Aug 2014, Ilya Grigorik wrote: I'm working on the resource hints spec we've been discussing on public-webperf... FYI, I'm currently working an a dependency system update to HTML which has the goals of: - merging HTML import dependency management and ES6 module dependency management infrastructure - defining preloading mechanisms for most HTML loading contexts - defining a dependency system for HTML loading contexts, especially style sheets, images, HTML imports, modules, and scripts - hooking most HTML loading contexts into the new Fetch API Assuming this works out as intended, it would completely subsume the resource hints proposal. My main blocker right now is the part where it gets integrated into the ES6 module system; it's requiring some very careful reading of the ES6 spec. I'm still in the middle of this. You can see my current results here: http://www.gliffy.com/go/publish/6040024 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Notifications improvements
On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson atwil...@google.com wrote:
On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo bever...@google.com
wrote:
Hi Andrew,
On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson atwil...@google.com
wrote:
On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson atwil...@google.com
wrote:
I understand your concern that is driving this proposal: you don't
want to provide rich APIs that can't be well implemented on every
platform, and thereby fragment the web platform. I just don't want to
see us go down this path of adding these new notification types that
are so limited in ability that people will just keep using general
notifications anyway - I'd rather just stick with the existing API.
Are you unenthusiastic about any of the proposed additions (what about
those already added?) or is this more about the more complex
features such as indication of progress?
I'm (somewhat) unenthusiastic about the new semantic types, because
I'm not sure they'd get enough uptake to be worth the effort to
implement (note that this is just my personal opinion - I'm no longer
as heavily involved in the notification work within Chromium, so Peter
B's opinion carries much more weight than mine when it comes to
determining what we'd implement).
I find myself being in favor of the semantic types.
The primary reason for this is that it allows us to provide a much more
consistent user experience, especially on platforms where we don't
control
rendering of the notification, compared to HTML notifications. On Chrome
for
Android we want to provide for a consistent user experience, where
notifications should be visually indistinguishable (aside from clarifying
the origin) from those created by native apps. The proposed semantic
types
would get us there.
Furthermore, support for HTML notifications will be much more difficult
to
implement across the board. Some mobile OSes, notably Firefox OS and iOS,
wouldn't support this at all. Others, such as Android, theoretically
could
support it, but won't because it means creating an entire WebView --
causing
very significant memory pressure on already resource constrained devices.
To be clear, I'm not arguing for HTML notifications - as I said in my
original post to this thread, HTML notifications were removed from the
spec for various good reasons. But I think it's a mistake to just bake
in canned notification types. What if a developer wants a progress bar
with a cancel button? A progress bar with a timestamp? A list
notification that contains an event with timestamp? Or some other
different notification that doesn't specifically match one of your
curated templates, but could easily be built if you gave him a
lower-level set of primitives?
You raise an interesting question. Given the following notification:
var notification = new Notification('Title', {
body: 'Hello, world!',
icon: '/my-icon.png',
items: [
{ title: 'Message 1', body: 'Contents of message 1' },
{ title: 'Message 2', body: 'Contents of message 2' },
{ title: 'Message 3', body: 'Contents of message 3' }
],
buttons: [
'Reply',
'Reply to all',
'Forward'
],
date: new Date('2014-08-11T16:35:00'),
progress: 40
});
What do we expect to be displayed?
I *think* Android can mix and match some of those, but expect at least
progress bars and lists of items to be mutually exclusive. I don't have a
good answer for this right now. UAs rendering their own notifications could
support this more easily, but it will still raise interesting UX questions.
Thanks,
Peter
Re: [whatwg] resource hints and separating download from processing
On Mon, Aug 11, 2014 at 8:33 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 7 Aug 2014, Ilya Grigorik wrote: I'm working on the resource hints spec we've been discussing on public-webperf... FYI, I'm currently working an a dependency system update to HTML which has the goals of: - merging HTML import dependency management and ES6 module dependency management infrastructure Will this result in API that extends beyond import and ES6 module use cases? For example, I want to have the building blocks that will allow me to declare these dependencies on my own: these two images before that script, but after this stylesheet, oh and that stylesheet should have higher priority than... We can express all of this in HTTP/2, and I'd like that to be surfaced to the developers as a first class API. - defining preloading mechanisms for most HTML loading contexts - defining a dependency system for HTML loading contexts, especially style sheets, images, HTML imports, modules, and scripts I'm looking at the gliffy, but having a hard time understanding how this will work... It's murky to me how I'd declare a resource, specify its priority relative to others, and/or add a dependency. Any other (more complete) examples, by any chance? :) - hooking most HTML loading contexts into the new Fetch API Great! Assuming this works out as intended, it would completely subsume the resource hints proposal. Hmm, not entirely.. I think. At a minimum, we still have preconnect and speculative preload + prerender cases to consider. ig
Re: [whatwg] resource hints and separating download from processing
On Mon, 11 Aug 2014, Ilya Grigorik wrote: Will this result in API that extends beyond import and ES6 module use cases? For example, I want to have the building blocks that will allow me to declare these dependencies on my own: these two images before that script, but after this stylesheet, oh and that stylesheet should have higher priority than... We can express all of this in HTTP/2, and I'd like that to be surfaced to the developers as a first class API. Yeah, this is the kind of thing I'm looking at. - defining preloading mechanisms for most HTML loading contexts - defining a dependency system for HTML loading contexts, especially style sheets, images, HTML imports, modules, and scripts I'm looking at the gliffy The gliffy is just a description of the ES6 module system. but having a hard time understanding how this will work... You and me both. It's murky to me how I'd declare a resource, specify its priority relative to others, and/or add a dependency. Any other (more complete) examples, by any chance? :) All of that is out of scope of ES6 (and thus the gliffy), but is what I'm trying to design. I hope to be able to post more concrete proposals soon, it's currently blocked on my understanding how I should be integrating HTML with ES6. Assuming this works out as intended, it would completely subsume the resource hints proposal. Hmm, not entirely.. I think. At a minimum, we still have preconnect and speculative preload + prerender cases to consider. Do you mean the case of fetching a file before you've loaded the base HTML file, as in loading a landing page before the user has selected a search result on a search engine, for example? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
On Mon, Aug 11, 2014 at 12:57 PM, Ian Hickson i...@hixie.ch wrote: It's murky to me how I'd declare a resource, specify its priority relative to others, and/or add a dependency. Any other (more complete) examples, by any chance? :) All of that is out of scope of ES6 (and thus the gliffy), but is what I'm trying to design. I hope to be able to post more concrete proposals soon, it's currently blocked on my understanding how I should be integrating HTML with ES6. Any bugs or threads that I can follow to track progress? I'd love to help if I can. Assuming this works out as intended, it would completely subsume the resource hints proposal. Hmm, not entirely.. I think. At a minimum, we still have preconnect and speculative preload + prerender cases to consider. Do you mean the case of fetching a file before you've loaded the base HTML file, as in loading a landing page before the user has selected a search result on a search engine, for example? Two high-level cases: (a) optimizing load sequence of page that's currently being loaded (b) optimizing page load of a (potential) future navigation For (a), we need to expose preconnect and preload, such that the developer and/or server (e.g. CDN accelerator) can tell the browser which hosts it should connect to, which resources it should load (+ with which priority, order), etc. Also, note that preload separates download from processing, which is an important feature - e.g. fetch CSS but don't evaluate it. For (b), we're talking about a speculative hint, hence we attach a probability to the hint and let the UA decide if it has enough resources / time / etc, to execute it, and how far it is willing to go with response processing. For more detailed use cases, check out Example 1-9: https://igrigorik.github.io/resource-hints/ ig
Re: [whatwg] Notifications improvements
On Aug 11, 2014 8:38 AM, Peter Beverloo bever...@google.com wrote:
On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson atwil...@google.com wrote:
You raise an interesting question. Given the following notification:
var notification = new Notification('Title', {
body: 'Hello, world!',
icon: '/my-icon.png',
items: [
{ title: 'Message 1', body: 'Contents of message 1' },
{ title: 'Message 2', body: 'Contents of message 2' },
{ title: 'Message 3', body: 'Contents of message 3' }
],
buttons: [
'Reply',
'Reply to all',
'Forward'
],
date: new Date('2014-08-11T16:35:00'),
progress: 40
});
What do we expect to be displayed?
I agree, this is a very interesting question. My thinking had been
that this should be supported. But I hadn't thought of that not all
platforms that can render a progress bar can render one at the same
time as a bullet list, or a set of buttons.
And then there's of course the question how the above would be
rendered, I.e. does the progress bar go above or below the list? Or is
that UA defined.
Suggestions for how to deal with this is definitely welcome.
I think we can expect that the date is simply displayed next to the
notification. Just like the icon is. That's how every notification
system I can find do it. Dates really are more about adjusting UI
which is already there, rather than adding new UI. So I would expect
that to mix fine with all other types of data.
Buttons, progressbar and lists are indeed a problem though. Does
anyone know what limitations we have as far as platforms go?
At a first glance, it seems like we might be able to get away with
defining that buttons are always at the bottom, and progress bars are
just above buttons but below everything else. But quite possibly
things aren't that simple.
Lists are trickier. They even seem tricky on their own. Do they go
before or after the text body? It seems like you might even want to
have a list in with text both before and after. Or should we say that
you can't have lists at the same time as a text body?
/ Jonas
