headers
Ian Hickson | 1 Jun 2011 01:17
Picon

Microdata feedback


On Tue, 15 Mar 2011, Hay (Husky) wrote:
> 
> Consider, for example, a list that contains custom data that needs to be 
> displayed using Javascript. In most cases, the data-* attributes are a 
> nice way to embed non-visual data to be read out later, but that doesn't 
> work for hierarchical structures.

You can use nested HTML elements with data-* attributes. For example, the 
JSON value {a:{b:'x',y:'z'}} could be represented as:

   <div data-a>
    <div data-b='x'></div>
    <div data-c='y'></div>
   </div>

> 1) Microdata. This could work, but only if the data should be displayed 
> as well. If the data should be processed (and for example, be shown in 
> another part of the page) this doesn't work really well. You could the 
> hide the parent element with CSS, but that's pretty clunky.

You can use microdata with <link> and <meta> if you don't want to actually 
show the information.

Hiding information in a page (whether it's in microdata, data-*, <script> 
data blocks, or anything else) if generally frowned upon as the data tends 
to end up less accurate than if it's visible, but that's something you 
have to take under advisement.

> 2) data-* attributes with JSON data. Would work, but pretty ugly and not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boris Zbarsky | 1 Jun 2011 03:12
Picon
Favicon

Re: DOMContentLoaded, load and current document readiness

On 5/31/11 6:37 PM, Aryeh Gregor wrote:
> How about:

[ugly code snipped]

That does work, yes (assuming your readyState check is correct; if not 
it can be fixed to be correct).

As you note, expecting web authors to do this is silly.  Forget figuring 
out or not; we just don't want to inflict this on people, even those who 
_can_ figure it out.

-Boris
Permalink | Reply | 0 comments |
headers
Bjartur Thorlacius | 1 Jun 2011 03:46
Picon

Re: Unlimited pageStorage for App Cached web pages

On 5/31/11, Felix Halim <felix.halim@...> wrote:
> On Mon, May 30, 2011 at 10:39 PM, Bjartur Thorlacius
> <svartman95@...> wrote:
>
> The dynamic resources only updated if the user visit the particular
> app cached web-page.
>
Yeah, that's logical. Caches should still be allowed to refetch
resources just before they're expected to be used. I might want my
home computer to fetch the latest news in the morning and evening, so
I can start reading when I wake up and when I get home from school.

> Remember that the dynamic resources I'm talking about here is NOT
> shared between other web-cached pages (even they are in the same
> domain).
>
That's fine. I don't think caches need to know that, but I'll get back
to you after some sleep. It may be hard to get quotas right; but
multiple HTML documents *could* link to the same resources. I think
quotas should only be enforced per resource and on the user agent,
leaving the user agent to use the quota for small files only as
effectively as it can, e.g. by keeping only frequently used resources.

>> The former is easy to achieve, but user agents tend to throw away stale
>> versions as to not present outdated information to the user and to save
>> storage space.
>
> The user agent only need to keep the latest version.
> It's fine to throw away the outdated one if you have the latest.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tommy Widenflycht (ᛏᚮᛘᛘᚤ | 1 Jun 2011 09:57
Picon
Favicon

Media Stream API: What is the intended behaviour for undefined mandatory arguments?

Hi Ian and the rest of the list,

We are having a bit of discussion regarding the correct behaviour
when mandatory arguments are undefined, see this webkit bug for history:
https://bugs.webkit.org/show_bug.cgi?id=60622

Could we have some clarification for the below cases, please:

var u;
var n = null;

// Should throw since u is undefined or just abort?
navigator.webkitGetUserMedia("audio", u);

// Will not throw but will abort.
navigator.webkitGetUserMedia("audio", n);

// Should throw because we are expecting at least two arguments.
navigator.webkitGetUserMedia("audio");

Thanks in advance,
Tommy

--

-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880

This email may be confidential or privileged. If you received this
communication by mistake, please don't forward it to anyone else, please
(Continue reading)

Permalink | Reply | 3 comments |
headers
Paul Kinlan | 1 Jun 2011 10:11
Picon
Favicon

Re: Question about "certain cases" for popstate event

Just wanting to ping this thread again.

I am running in to a couple of issues with spec and apparently undefined
cases:

   1. This case, when does popstate actually fire? We
   have inconsistencies in apparent implementation.
   2. We have no way to detect onpushstate events
   http://paul.kinlan.me/html5-history-needs-another-event so we can't tell
   when the URL changes.
   3. When combining pushState with AppCache, the urls that are navigated
   too via pushState are not added to the application cache groups - and I
   think they should.

I am keen to move this forward and would love to work out the best ways.

P

On Thu, Apr 14, 2011 at 2:56 PM, Rafał Miłecki <zajec5@...> wrote:

> W dniu 5 kwietnia 2011 13:03 użytkownik Rafał Miłecki
> <zajec5@...> napisał:
> > Hello,
> >
> > There is part of the spec that do not see too obvious for me. Could
> > you help me with that?
> >
> > 6.5.9.1 says:
> >> The popstate event is fired in certain cases when navigating to a
> session history entry.
(Continue reading)

Permalink | Reply | 0 comments |
headers
ilya goberman | 1 Jun 2011 20:23
Picon
Favicon

Enhancement request: change EventSource to allow cross-domain access


Can EventSource be enhanced to support cross-domain requests via "Access-Control-Allow-Origin"
header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests.

I filed a request with WebKit bugzilla and they suggested to send it to you: https://bugs.webkit.org/show_bug.cgi?id=61862

The rationale and use cases are exactly the same as for XHR: it can be useful to access different domains.
Is support for EventSource cross domains planned at all? It is supposedly one of the most requested
features, but I do not know how it is tracked.
Thanks
Permalink | Reply | 24 comments |
headers
Edward Gerhold | 1 Jun 2011 21:07
Gravatar

Application Cache

Dear Friends of HTML5,

i think i have the topic back on the list in my mind. I know already two
workarounds.

1) Whitelisting the index file (having the manifest) - create a splash
screen to walk through. Whitelist the (previous) master file like a normal
network resource there.
For a CMS with scripts, css and images from Disk, create a
example.com/cached-version-start.html with the manifest. Whitelist the
master, where you wanted the manifest before. You can go through "a door or
a splash screen" for a half-cached-site, where scripts and styles with long
loading times come from disk.

2) Adding files to the cache. The Video HTML5 Wow and the How demonstrates
the FileAPI. Ok, with this API and some Storage i can write down all the
pages received. This will be what i will use, if i can´t bring the additions
to the cache.

The two are no excuses for letting the few functions for the cache out of
the cache. The media there is already grouped as normal pages and media and
behave like. You don´t have to do much more working around with the file
api, to reach the implementation of the cache, ok, you got to do the same
work. But only once, to add the functions. FileAPI users would have to write
a cache-lib or programm that every application again. I think the cache
would benefit from it´s expansion.

I think the Manifest Container is a good Spot. But i prefer to add Classes
for the three List containers, extending the Vector and the Map a little.
This seems to be better programming for me,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Edward Gerhold | 1 Jun 2011 21:32
Gravatar

Pain with the Headers in webkit/appcache.

Me again..

Won´t continue writing down every step. But my next look, i´ll be motivated
now, tells me one thing:

Create a _new header_ with the Interfaces, and work on the manifest
structure. This is what the rest of the files in webkit/appcache do with all
the data.
I shouldn´t write the functions into class Manifest. Simply work with the
existing Manifest and the Operations get the Lists and do something with.
How to read and write the Page data, that is written in the code in the
other Files. The class Manifest is bound to the manifest parser file.
I could call it manifest_manipulator or think again about it. But i think,
being better readable and fitting better in webkit, i shouldn´t write into
manifest_parser.

Is it easier to add a new file to such a branch or to patch an existing?
Looks it better to seperate the new functions from the manifest, even if
they belong, too?
Good, i´ll find out.

Uhm, and another workaround for the update function in a CMS is to let the
CMS generate the manifest again with new version number and the additional
or removed files.
Make sure to document, that people using your cached site, would sometimes
rather check chrome://appcache-internals and delete, than waiting for any
update to be sure,
to check out the latest. But that is only working around the statics of the
application cache.
(Continue reading)

Permalink | Reply | 19 comments |
headers
Aryeh Gregor | 1 Jun 2011 22:09
Picon

Re: Media Stream API: What is the intended behaviour for undefined mandatory arguments?

2011/6/1 Tommy Widenflycht (ᛏᚮᛘᛘᚤ) <tommyw@...>:
> Hi Ian and the rest of the list,
>
> We are having a bit of discussion regarding the correct behaviour
> when mandatory arguments are undefined, see this webkit bug for history:
> https://bugs.webkit.org/show_bug.cgi?id=60622
>
> Could we have some clarification for the below cases, please:
>
> var u;
> var n = null;
>
> // Should throw since u is undefined or just abort?
> navigator.webkitGetUserMedia("audio", u);
>
> // Will not throw but will abort.
> navigator.webkitGetUserMedia("audio", n);
>
> // Should throw because we are expecting at least two arguments.
> navigator.webkitGetUserMedia("audio");

This is defined by WebIDL, although somewhat complicatedly:

http://dev.w3.org/2006/webapi/WebIDL/#es-operations

The key is the two steps "Initialize S to the effective overload set .
. ." and "Set S to the result of passing S and arg0..n−1 to the
overload resolution algorithm."  Basically, that means "Let S be the
set of all the methods with this name on this object, then remove from
the set any methods that can't accept the provided arguments."  I
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonas Sicking | 2 Jun 2011 00:23
Gravatar

Re: Enhancement request: change EventSource to allow cross-domain access

On Wed, Jun 1, 2011 at 11:23 AM, ilya goberman <goberman@...> wrote:
>
> Can EventSource be enhanced to support cross-domain requests via "Access-Control-Allow-Origin"
header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests.
>
> I filed a request with WebKit bugzilla and they suggested to send it to you: https://bugs.webkit.org/show_bug.cgi?id=61862
>
> The rationale and use cases are exactly the same as for XHR: it can be useful to access different domains.
> Is support for EventSource cross domains planned at all? It is supposedly one of the most requested
features, but I do not know how it is tracked.

I absolutely think we should do this. I was in fact quite surprised to
find that this wasn't already the case.

Getting event streams from other sites seems like a prime use case for
EventSource.

We should probably consider adding the ability to specify if you want
the request to happen with or without credentials (and default to the
safe option which is without credentials).

/ Jonas
Permalink | Reply | 0 comments |

Gmane