Re: [whatwg] adding microdata to basic links

[Stéphane Corlosquet]

Hi Ian,

On Thu, Dec 8, 2011 at 5:11 PM, Ian Hickson  wrote:

> On Wed, 24 Aug 2011, Stéphane Corlosquet wrote:
> >
> > Starting from a basic markup like this:
> > [[[
> > This book has been authored by http://smith.org/john";>John
> > Smith.
> > ]]]
> >
> > I would like to markup both the textContent of the link ("John Smith")
> and
> > the url from the href attribute.
> >
> > In RDFa this is done by adding a couple of attributes to the a element.
> It
> > would read like this:
> > [[[
> > This book has been authored by http://smith.org/john";>John Smith.
> > ]]]
> >
> > Is there any way to do the same in microdata without adding a new HTML
> > element to the markup?
>
> On Wed, 24 Aug 2011, Tab Atkins Jr. wrote:
> >
> > No, Microdata purposely keeps its data model simple by expressing
> > property names through a single attribute.  Since having @itemprop on an
> >  always refers to the @href of the element, you must nest an
> > additional element, such as a , into your markup to carry the
> > property that refers to the text content.
>
> Indeed.
>
> The reasoning is that it's hard to understand otherwise; e.g. it's not at
> all immediately obvious to me that this is wrong, though it is:
>
>   http://smith.org/john";>John Smith
>

I agree, and I have seen people doing that mistake (including myself!). The
RDFa WG received a lot of similar feedback, so it was decided to do
something about it. While the snippet above is wrong in RDFa 1.0, it is
correct in RDFa 1.1 (@property will pick up @href if there is no @rel). So
you can write RDFa without using @rel in the same fashion as microdata.
That's a good example of microdata design feeding into other standards.

Steph.


>
> ...and while an experienced author would know that "rel" is to "href" as
> "property" is to the contents, an inexperienced one might still make
> mistakes such as:
>
>   http://smith.org/john";
>  rel="name">John Smith
>
> In microdata,  always gives the URL, which simplifies it a bit, at the
> cost of making this example more verbose.
>
>
> On Wed, 24 Aug 2011, Tantek Ã~Gelik wrote:
> >
> > This does seem to be a (fairly common) case where microdata requires
> > additional markup (another element) whereas both microformats (e.g.
> > hCard) and [RDFa] (through the perhaps questionable overloading of
> > 'rel') do not.
>
> Yeah. Microformats 2 has an interesting compromise solution where
> Hungarian notation is used to denote the type of the property, and that
> type is used to determine how it is read. The cost of that of course is
> the slightly more verbose markup in all property names.
>
>
> On Wed, 24 Aug 2011, Stéphane Corlosquet wrote [edited for simplicity]:
> >
> > [[[
> > This book has been authored by
> > http://schema.org/"; typeof="Person">
> > http://smith.org/john";>John
> > Smith
> > 
> > ]]]
>
> On Wed, 24 Aug 2011, Edward O'Connor wrote [edited for brevity]:
> >
> > This could be represented in Microdata without an extra element:
>
> Well, microdata needs to use an element that is undecorated in the
> original, namely the  that I removed in the quote above:
>
> > http://schema.org/Person";>
> > This book has been authored by
> > 
> > http://smith.org/john";>John
> > Smith
> > 
> > 
>
> The microformats for this particular case is shorter still.
>
>
> I haven't changed microdata for this; the current design is an intentional
> trade-off between verbosity and predictability.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Behavior when

[Mark S. Miller]

The argument I was making is that there's no reason to carve out a special
case for JSON, as opposed to all text that parses as JavaScript. Since
then, Jonas made a sensible counterargument. At least for now, I withdraw
the suggestion.


On Thursday, December 8, 2011, Yehuda Katz wrote:

>
> Yehuda Katz
> (ph) 718.877.1325
>
>
> On Thu, Dec 8, 2011 at 4:31 PM, Mark S. Miller  wrote:
>
>> On Thursday, December 8, 2011, Yehuda Katz wrote:
>>
>>>
>>> I'm probably still misunderstanding, but the current security
>>> infrastructure of the web supports cross-origin XHR only with a new kind of
>>> explicit server opt-in that most APIs do not support.
>>>
>>
>>
>> In that case you are understanding correctly. My point was that *except
>> for the lack of this header*, the rest of this JSONP API is just a one
>> liner.
>>
>
> Yes, but how does that help us?
>
>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
>

-- 
Cheers,
--MarkM

Re: [whatwg] Behavior when

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Thu, Dec 8, 2011 at 4:31 PM, Mark S. Miller  wrote:

> On Thursday, December 8, 2011, Yehuda Katz wrote:
>
>>
>> I'm probably still misunderstanding, but the current security
>> infrastructure of the web supports cross-origin XHR only with a new kind of
>> explicit server opt-in that most APIs do not support.
>>
>
>
> In that case you are understanding correctly. My point was that *except
> for the lack of this header*, the rest of this JSONP API is just a one
> liner.
>

Yes, but how does that help us?


>
>
> --
> Cheers,
> --MarkM
>

Re: [whatwg] Behavior when

[Mark S. Miller]

On Thursday, December 8, 2011, Yehuda Katz wrote:

>
> I'm probably still misunderstanding, but the current security
> infrastructure of the web supports cross-origin XHR only with a new kind of
> explicit server opt-in that most APIs do not support.
>


In that case you are understanding correctly. My point was that *except for
the lack of this header*, the rest of this JSONP API is just a one liner.


-- 
Cheers,
--MarkM

Re: [whatwg] Function "Active Menu"

[Ian Hickson]

On Sat, 7 May 2011, Jos� Lucas Teixeira de Oliveira wrote:
> 
> I think there should be a way to bind a link tag "" with a 
> "" specific, creating a function of "active menu" automatically 
> in HTML5. What is your opinion?

On Sat, 7 May 2011, Kit Grose wrote:
>
> Possibly an even more generic case for this would be when an anchor 
> tag's href attribute points to the current URL, allowing for any type of 
> content (article or otherwise) to get simple active nav item selection.

On Sat, 7 May 2011, Jos� Lucas Teixeira de Oliveira wrote:
>
> I agree with you Kit, this is an even better suggestion that would 
> greatly facilitate the work of developers, save time and performance, 
> eliminating the use of other languages ​​to accomplish such a feat.

On Sat, 7 May 2011, Benjamin Hawkes-Lewis wrote:
> 
> I don't understand what problem you're trying to solve, or what user 
> agent behavior you are proposing.

Me either. It would be helpful to have a clearer problem description so 
that I could more adequately evaluate the proposal and determine how to 
address it, and indeed whether it is worth addressing.


On Sat, 7 May 2011, André Luís wrote:
>
> Recognizing that the href is the same as the current uri.
> 
> I agree it woud be nice, but I see this as a proposal for the css wg. 
> This has pseudo-class written all over this.
> 
> :current or something.
> 
> Nowadays we solve this with a .current or .active class name.
> 
> Not exactly life-changing, but useful nonetheless.

This may be of interest:

   http://dev.w3.org/csswg/selectors4/#local-pseudo

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

Re: [whatwg] Behavior when

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Thu, Dec 8, 2011 at 3:15 PM, Mark S. Miller  wrote:

>
>
> On Thursday, December 8, 2011, Yehuda Katz wrote:
>
>>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>>
>> On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller wrote:
>>
>>> Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
>>> header, the API you suggest below can be fully implemented as a library.
>>>
>>> Since any response that parses as JavaScript has no same origin
>>> protection anyway, rather than carve out a special case for JSONP, should
>>> we waive the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that
>>> parse as JavaScript for XHR requests in general? If not, what justifies
>>> carving out a special case for JSONP?
>>>
>>
>> In the general case, executed JavaScript does not expose the content.
>>
>
> The legacy content we're concerned with is written to work on ES3
> browsers. By overriding "Object" and "Array", or by other subterfuge, you
> can corrupt an ES3 environment adequately to violate the confidentiality of
> scripts loaded later into the same frame. Anne Van Kesteren pointed out the
> only form of confidentiality we can be confident of in this context:
> comments (and whitespace and choice of internal variable names). Are these
> secrets worth giving up on the safety that could result from loading these
> scripts as data, so that we could then run them in a restricted manner
> (whether by translation, verification, or other tricks, e.g., SES)?
>
>
>
>> Existing JSONP implementations obviously work as libraries, but
>> implementing them robustly is non-trivial. Given that we know that this
>> subset is already secure (or at least, doesn't add any new security
>> issues), creating an explicit API that eliminated the library fiddliness
>> (and need for registering a global function) would be great.
>>
>
> That you say "registering a global function" leaves me suspecting you
> don't understand my suggestion. Assuming ES5 and some form of
> origin-independent or cross-origin xhr, very simple JavaScript code can
> fetch the JSONP payload as data, strip the prefix and suffix, and use
> JSON.parse on the remaining string. I mean, c'mon, it's probably a one
> liner. Do we really need to add a new special case to the security
> architecture of the browser in order to avoid this one liner?
>

I'm probably still misunderstanding, but the current security
infrastructure of the web supports cross-origin XHR only with a new kind of
explicit server opt-in that most APIs do not support.


>
>
>
>>
>>
>>>
>>>
>>> On Wed, Dec 7, 2011 at 5:20 PM, Jonas Sicking  wrote:
>>>
 On Wed, Dec 7, 2011 at 3:55 PM, Yehuda Katz  wrote:
 >
 > Yehuda Katz
 > (ph) 718.877.1325
 >
 >
 > On Wed, Dec 7, 2011 at 3:43 PM, Jonas Sicking 
 wrote:
 >>
 >> On Wed, Dec 7, 2011 at 12:39 PM, Yehuda Katz 
 wrote:
 >> > Yehuda Katz
 >> > (ph) 718.877.1325
 >> >
 >> >
 >> > On Wed, Dec 7, 2011 at 12:29 PM, Boris Zbarsky 
 wrote:
 >> >
 >> >> On 12/7/11 3:22 PM, Joshua Bell wrote:
 >> >>
 >> >>> This can't be implemented in JS today (e.g. as a shim) since that
 >> >>> "evaluate
 >> >>> this script text in this new global sandbox" bit isn't present.
 >> >>>
 >> >>
 >> >> It can sort of be done via opening a new window and setting its
 opener
 >> >> to
 >> >> null before injecting some 

Re: [whatwg] Behavior when

[Jonas Sicking]

On Thu, Dec 8, 2011 at 3:15 PM, Mark S. Miller  wrote:
>
>
> On Thursday, December 8, 2011, Yehuda Katz wrote:
>>
>>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>>
>> On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller  wrote:
>>>
>>> Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
>>> header, the API you suggest below can be fully implemented as a library.
>>>
>>> Since any response that parses as JavaScript has no same origin
>>> protection anyway, rather than carve out a special case for JSONP, should we
>>> waive the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse
>>> as JavaScript for XHR requests in general? If not, what justifies carving
>>> out a special case for JSONP?
>>
>>
>> In the general case, executed JavaScript does not expose the content.
>
>
> The legacy content we're concerned with is written to work on ES3 browsers.
> By overriding "Object" and "Array", or by other subterfuge, you can corrupt
> an ES3 environment adequately to violate the confidentiality of scripts
> loaded later into the same frame. Anne Van Kesteren pointed out the only
> form of confidentiality we can be confident of in this context: comments
> (and whitespace and choice of internal variable names). Are these secrets
> worth giving up on the safety that could result from loading these scripts
> as data, so that we could then run them in a restricted manner (whether by
> translation, verification, or other tricks, e.g., SES)?

Yet browsers jump through hoops to not expose the contents of
cross-origin scripts in error messages and the like.

I would personally not be happy with Firefox exposing the contents of
any cross-origin resource just because it happened to parse as
javascript. Especially since JSON has become so popular as a mechanism
to load data from a same-origin server. I don't know how other browser
vendors feel.

This is why I used the strict definition of JSONP since such data can
irrefutably be loaded cross-origin in all versions of all popular
browsers.

/ Jonas

Re: [whatwg] Behavior when

[Mark S. Miller]

On Thursday, December 8, 2011, Mark S. Miller wrote:

> [...] Anne Van Kesteren pointed out the only form of confidentiality we
> can be confident of in this context: comments (and whitespace and choice of
> internal variable names).
>

Anne said only "comments". I added the parenthetical. After a moment's
reflection I realize this extension is wrong -- because of
Function.prototype.toString. I do not know whether comments are safely
omitted from this across all major browsers. If so, then Anne's statement
is exactly right. If not, then all we can say is "comments and whitespace
at top level -- outside of any function."


> --
> Cheers,
> --MarkM
>


-- 
Cheers,
--MarkM

Re: [whatwg] Behavior when

[Mark S. Miller]

On Thursday, December 8, 2011, Yehuda Katz wrote:

>
> Yehuda Katz
> (ph) 718.877.1325
>
>
> On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller 
> 
> > wrote:
>
>> Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
>> header, the API you suggest below can be fully implemented as a library.
>>
>> Since any response that parses as JavaScript has no same origin
>> protection anyway, rather than carve out a special case for JSONP, should
>> we waive the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that
>> parse as JavaScript for XHR requests in general? If not, what justifies
>> carving out a special case for JSONP?
>>
>
> In the general case, executed JavaScript does not expose the content.
>

The legacy content we're concerned with is written to work on ES3 browsers.
By overriding "Object" and "Array", or by other subterfuge, you can corrupt
an ES3 environment adequately to violate the confidentiality of scripts
loaded later into the same frame. Anne Van Kesteren pointed out the only
form of confidentiality we can be confident of in this context: comments
(and whitespace and choice of internal variable names). Are these secrets
worth giving up on the safety that could result from loading these scripts
as data, so that we could then run them in a restricted manner (whether by
translation, verification, or other tricks, e.g., SES)?



> Existing JSONP implementations obviously work as libraries, but
> implementing them robustly is non-trivial. Given that we know that this
> subset is already secure (or at least, doesn't add any new security
> issues), creating an explicit API that eliminated the library fiddliness
> (and need for registering a global function) would be great.
>

That you say "registering a global function" leaves me suspecting you don't
understand my suggestion. Assuming ES5 and some form of origin-independent
or cross-origin xhr, very simple JavaScript code can fetch the JSONP
payload as data, strip the prefix and suffix, and use JSON.parse on the
remaining string. I mean, c'mon, it's probably a one liner. Do we really
need to add a new special case to the security architecture of the browser
in order to avoid this one liner?



>
>
>>
>>
>> On Wed, Dec 7, 2011 at 5:20 PM, Jonas Sicking  wrote:
>>
>>> On Wed, Dec 7, 2011 at 3:55 PM, Yehuda Katz 
>>> >
>>> wrote:
>>> >
>>> > Yehuda Katz
>>> > (ph) 718.877.1325
>>> >
>>> >
>>> > On Wed, Dec 7, 2011 at 3:43 PM, Jonas Sicking 
>>> wrote:
>>> >>
>>> >> On Wed, Dec 7, 2011 at 12:39 PM, Yehuda Katz 
>>> >> >
>>> wrote:
>>> >> > Yehuda Katz
>>> >> > (ph) 718.877.1325
>>> >> >
>>> >> >
>>> >> > On Wed, Dec 7, 2011 at 12:29 PM, Boris Zbarsky 
>>> >> > >
>>> wrote:
>>> >> >
>>> >> >> On 12/7/11 3:22 PM, Joshua Bell wrote:
>>> >> >>
>>> >> >>> This can't be implemented in JS today (e.g. as a shim) since that
>>> >> >>> "evaluate
>>> >> >>> this script text in this new global sandbox" bit isn't present.
>>> >> >>>
>>> >> >>
>>> >> >> It can sort of be done via opening a new window and setting its
>>> opener
>>> >> >> to
>>> >> >> null before injecting some 

Re: [whatwg] WebSocket framing

[Ian Hickson]

On Sun, 21 Aug 2011, Bronislav Klu�~Mka wrote:
>
> 1/ and I'm missing the ability to specify, whether data to be sent are 
> final or not (whether the frame to be sent should be continuous or not) 
> I suppose some parameter for specifying final/continuing frame should be 
> there, or some new methods for framing. I've tried to send 100 MiB text 
> from Chrome for testing purposes and since there is no way to specify 
> framing it was send in one piece.  There is no way to stream data from 
> client to server, all data must be kept in memory and sent at once.

Whether the frames are split into multiple frames or not is a browser 
decision; at the API level you just say what to send and let the browser 
take care of it. It doesn't have to be kept in memory; in fact, if you're 
sending a Blob, for example, it's quite possible that the whole thing will 
never be stored in RAM. In certain architectures it might never be stored 
in RAM, but be sent straight from the disk controller to the network 
controller bypassing RAM and the CPU entirely.


> 2/ The same issue for receiving. I understand the need for simple API. 
> But again, there is streaming ability missing, all data are received at 
> once. Receiving large amount of data could hang up browser. There should 
> be onFrameMessage event intercepting frames one by one and (probably by 
> some event property) define, whether all those frames should be cached 
> and finally exposed by onMessage event (true by default). Programmer 
> than can choose to ignore such event (not implement it) and receive all 
> messages by onmessage event or implement it, use it for streaming, and 
> possibly prevent onMessage calls and unnecessary caching of large data

Supporting sending and receiving streams is something that we'll probably 
add in due course. First we have to actually have streams at all in the 
Web platform.


> 3/ MessageEvent should expose what kind of data was received, textual, 
> blob or arrayBuffer. This would prevent testing for data type and 
> problems with testing |binaryType 
>  |property 
> if changed during data receiving.

I don't really follow here. Isn't the type just going to be what you ask 
for?


On Mon, 22 Aug 2011, James Graham wrote:
> 
> I imagine that at some point in the future we will expose an interface 
> that is optimised for streaming data over websockets. But it seems 
> foolhardy to do that before we have any real-world experience with the 
> basic API. It is also something that will need to be designed to 
> integrate with other streaming APIs in the platform, e.g. the audio and 
> video stuff that is currently being discussed (mostly elsewhere).

Indeed.

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

Re: [whatwg] Use of media queries to limit bandwidth/data transfer

[Boris Zbarsky]

On 12/8/11 5:10 PM, James Graham wrote:

It's not clear that device-width and device-height should be encouraged
since they don't tell you anything about how much content area is
*actually* visible to the user.


Well, sure.  I'm not saying using them is a good idea, just that people 
are doing it.


-Boris

Re: [whatwg] Behavior when

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Thu, Dec 8, 2011 at 3:00 PM, Mark S. Miller  wrote:

>
>
> On Thursday, December 8, 2011, Jonas Sicking wrote:
>
>> On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller 
>> wrote:
>> > Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
>> > header, the API you suggest below can be fully implemented as a library.
>> >
>> > Since any response that parses as JavaScript has no same origin
>> protection
>> > anyway, rather than carve out a special case for JSONP, should we waive
>> > the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse as
>> > JavaScript for XHR requests in general? If not, what justifies carving
>> out a
>> > special case for JSONP?
>>
>> There's two *possible* reasons to treat JSONP special.
>>
>> The weak reason would be to support existing JSONP-serving servers
>> which are out there already. JSONP appears to be one of the more
>> popular formats for HTTP-based APIs right now.
>>
>> The stronger reason is that it appears that people have a very hard
>> time setting http headers. While this seems surprising to me,
>> especially in situations like this where you already have server-side
>> scripts generating dynamic content, it is feedback that I get *a lot*.
>>
>> Another option would be some way to express CORS signals inline in
>> content. This actually existed in early CORS drafts, but only for XML
>> based contents which made it a lot less appealing. Especially since
>> the XML based content had to be served with a proper Content-Type
>> header which puts us back at square one.
>>
>
> My suggestion is that if the response parses as a JavaScript Program, this
> is interpreted as an inline signal, since same-origin protection for these
> responses make no sense. The reason why you're willing to carve out a
> special case for JSONP is precisely because these responses, parsing as
> JavaScript, are not protected by same-origin.
>

It is possible that the data in responses that nominally parse as
JavaScript would not normally be available to cross-origin pages, no?


>
>
>
>>
>> / Jonas
>>
>
>
> --
> Cheers,
> --MarkM
>

Re: [whatwg] Behavior when

[Mark S. Miller]

On Thursday, December 8, 2011, Jonas Sicking wrote:

> On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller 
> >
> wrote:
> > Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
> > header, the API you suggest below can be fully implemented as a library.
> >
> > Since any response that parses as JavaScript has no same origin
> protection
> > anyway, rather than carve out a special case for JSONP, should we waive
> > the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse as
> > JavaScript for XHR requests in general? If not, what justifies carving
> out a
> > special case for JSONP?
>
> There's two *possible* reasons to treat JSONP special.
>
> The weak reason would be to support existing JSONP-serving servers
> which are out there already. JSONP appears to be one of the more
> popular formats for HTTP-based APIs right now.
>
> The stronger reason is that it appears that people have a very hard
> time setting http headers. While this seems surprising to me,
> especially in situations like this where you already have server-side
> scripts generating dynamic content, it is feedback that I get *a lot*.
>
> Another option would be some way to express CORS signals inline in
> content. This actually existed in early CORS drafts, but only for XML
> based contents which made it a lot less appealing. Especially since
> the XML based content had to be served with a proper Content-Type
> header which puts us back at square one.
>

My suggestion is that if the response parses as a JavaScript Program, this
is interpreted as an inline signal, since same-origin protection for these
responses make no sense. The reason why you're willing to carve out a
special case for JSONP is precisely because these responses, parsing as
JavaScript, are not protected by same-origin.



>
> / Jonas
>


-- 
Cheers,
--MarkM

Re: [whatwg] microdata: itemprop in tag

[Ian Hickson]

On Sun, 16 Oct 2011, David Karger wrote:
>
> One natural way to represent a collection of structured items is in an 
> html table.  this can coexist with microdata, by using  
> and  tags.  But by ignoring the structure of the table, 
> this creates a lot of redundant attribute specification.
> 
> It would yield cleaner markup if it were possible to use  itemprop="foo"> to indicate an item property that should be inherited by 
> all cells in the given column.  In other words, to assert that any  
> associated with a  should inherit the itemprop associated with that 
>  .
> 
> It would yield even cleaner markup if there were a way to indicate that 
> every  was a distinct itemscope (the common case).  For example, to 
> use  to indicate that each row of the table scopes 
> an item of type bar.  Or perhaps  could be interpreted 
> as asserting a distinct itemscope for each row without specifying a 
> type.
> 
> But even using just the  inheritance rule, while still placing 
> itemscope in  tags, would save a quadratic quantity of markup.

Yeah, microdata doesn't handle tables well.

I'm a little reluctant to add magic to handle tables, because it can make 
it quite hard to work out what's going on, and it's not clear how common 
the problem really is. If it turns out to be a common issue, then it's 
something we should definitely consider, though.


On Sun, 16 Oct 2011, Tab Atkins Jr. wrote:
> 
> Just put an @itemref on each , pointing to the s that are part 
> of that column.  It's more verbose, but it doesn't rely on special 
> HTML-only rules.

That's a possible workaround for now, true.

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

Re: [whatwg] Behavior when

[Jonas Sicking]

On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller  wrote:
> Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
> header, the API you suggest below can be fully implemented as a library.
>
> Since any response that parses as JavaScript has no same origin protection
> anyway, rather than carve out a special case for JSONP, should we waive
> the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse as
> JavaScript for XHR requests in general? If not, what justifies carving out a
> special case for JSONP?

There's two *possible* reasons to treat JSONP special.

The weak reason would be to support existing JSONP-serving servers
which are out there already. JSONP appears to be one of the more
popular formats for HTTP-based APIs right now.

The stronger reason is that it appears that people have a very hard
time setting http headers. While this seems surprising to me,
especially in situations like this where you already have server-side
scripts generating dynamic content, it is feedback that I get *a lot*.

Another option would be some way to express CORS signals inline in
content. This actually existed in early CORS drafts, but only for XML
based contents which made it a lot less appealing. Especially since
the XML based content had to be served with a proper Content-Type
header which puts us back at square one.

/ Jonas

Re: [whatwg] Default encoding to UTF-8?

[Leif Halvard Silli]

Henri Sivonen Tue Dec 6 23:45:11 PST 2011:
> On Mon, Dec 5, 2011 at 7:42 PM, Leif Halvard Silli wrote:

> Mozilla grants localizers a lot of latitude here. The defaults you see
> are not carefully chosen by a committee of encoding strategists doing
> whole-Web optimization at Mozilla.

We could use such a committee for the Web!

> They are chosen by individual
> localizers. Looking at which locales default to UTF-8, I think the
> most probable explanation is that the localizers mistakenly tried to
> pick an encoding that fits the language of the localization instead of
> picking an encoding that's the most successful at decoding unlabeled
> pages most likely read by users of the localization

These localizations are nevertheless live tests. If we want to move 
more firmly in the direction of UTF-8, one could ask users of those 
'live tests' about their experience.

> (which means
> *other-language* pages when the language of the localization doesn't
> have a pre-UTF-8 legacy).

Do you have any concrete examples? And are there user complaints?

The Serb localization uses UTF-8. The Croat uses Win-1252, but only on 
Windows and Mac: On Linux it appears to use UTF-8, if I read the HG 
repository correctly. As for Croat and Window-1252, then it does not 
even support the Croat alphabet (in full) - I think about the digraphs. 
But I'm not sure about the pre-UTF-8 legacy for Croatian.

Some language communities in Russia have a similar minority situation 
as Serb Cyrillic, only that their minority script is Latin: They use 
Cyrillic but they may also use Latin. But in Russia, Cyrillic 
dominates. Hence it seems to be the case - according to my earlier 
findings, that those few letters that, per each language, do not occur 
in Window-1251, are inserted as NCRs (that is: when UTF-8 is not used). 
That way, WIN-1251 can be used for Latin with non-ASCII inside. But 
given that Croat defaults to WIn-1252, they could in theory just use 
NCRs too ...

Btw, for Safari on Mac, I'm unable to see any effect of switching 
locale: Always Win-1252 (Latin) - it used to have effect before ... But 
may be there is an parameter I'm unaware of - like Apple's knowledge of 
where in the World I live ...

> I think that defaulting to UTF-8 is always a bug, because at the time
> these localizations were launched, there should have been no unlabeled
> UTF-8 legacy, because up until these locales were launched, no
> browsers defaulted to UTF-8 (broadly speaking). I think defaulting to
> UTF-8 is harmful, because it makes it possible for locale-siloed
> unlabeled UTF-8 content come to existence

The current legacy encodings nevertheless creates siloed pages already. 
I'm also not sure that it would be a problem with such a UTF-8 silo: 
UTF-8 is possible to detect, for browsers - Chrome seems to perform 
more such detection than other browsers.

Today, perhaps especially for English users, it happens all the time 
that a page - without notice - defaults with regard to encoding - and 
this causes the browser - when used as an authoring tool - defaults to 
Windows-1252: http://twitter.com/#!/komputist/status/144834229610614784 
(I suppose he used that browser based spec authoring tool that is in 
development.) 

In another message you suggested I 'lobby' against authoring tools. OK. 
But the browser is also an authoring tool. So how can we have authors 
output UTF-8, by default, without changing the parsing default?

> (instead of guiding all Web
> authors always to declare their use of UTF-8 so that the content works
> with all browser locale configurations).

On must guide authors to do this regardless.

> I have tried to lobby internally at Mozilla for stricter localizer
> oversight here but have failed. (I'm particularly worried about
> localizers turning the heuristic detector on by default for their
> locale when it's not absolutely needed, because that's actually
> performance-sensitive and less likely to be corrected by the user.
> Therefore, turning the heuristic detector on may do performance
> reputation damage. )

W.r.t. heuristic detector: Testing the default encoding behaviour for 
Firefox was difficult. But in the end I understood that I must delete 
the cached version of the Profile folder - only then would the 
encodings 'fall back' properly. But before I came thus far, I tried 
with the e.g. the Russian version of Firefox, and discovered that it 
enabled the encoding heuristics: Thus it worked! Had it not done that, 
then it would instead have used Windows-1252 as the default ... So you 
perhaps need to be careful before telling them to disable heuristics ...

Btw: In Firefox, then in one sense, it is impossible to disable 
"automatic" character detection: In Firefox, overriding of the encoding 
only lasts until the next reload. However, I just discovered that in 
Opera, this is not the case: If you select Windows-1252 in Opera, then 
it will always - but online the current Tab -  be Windows-1252, even if 
there is a BOM a

Re: [whatwg] adding microdata to basic links

[Ian Hickson]

On Wed, 24 Aug 2011, St�phane Corlosquet wrote:
>
> Starting from a basic markup like this:
> [[[
> This book has been authored by http://smith.org/john";>John
> Smith.
> ]]]
> 
> I would like to markup both the textContent of the link ("John Smith") and
> the url from the href attribute.
> 
> In RDFa this is done by adding a couple of attributes to the a element. It
> would read like this:
> [[[
> This book has been authored by http://smith.org/john";>John Smith.
> ]]]
> 
> Is there any way to do the same in microdata without adding a new HTML
> element to the markup?

On Wed, 24 Aug 2011, Tab Atkins Jr. wrote:
> 
> No, Microdata purposely keeps its data model simple by expressing 
> property names through a single attribute.  Since having @itemprop on an 
>  always refers to the @href of the element, you must nest an 
> additional element, such as a , into your markup to carry the 
> property that refers to the text content.

Indeed.

The reasoning is that it's hard to understand otherwise; e.g. it's not at 
all immediately obvious to me that this is wrong, though it is:

   http://smith.org/john";>John Smith

...and while an experienced author would know that "rel" is to "href" as 
"property" is to the contents, an inexperienced one might still make 
mistakes such as:

   http://smith.org/john";
  rel="name">John Smith

In microdata,  always gives the URL, which simplifies it a bit, at the
cost of making this example more verbose.


On Wed, 24 Aug 2011, Tantek �~Gelik wrote:
>
> This does seem to be a (fairly common) case where microdata requires 
> additional markup (another element) whereas both microformats (e.g. 
> hCard) and [RDFa] (through the perhaps questionable overloading of 
> 'rel') do not.

Yeah. Microformats 2 has an interesting compromise solution where 
Hungarian notation is used to denote the type of the property, and that 
type is used to determine how it is read. The cost of that of course is 
the slightly more verbose markup in all property names.


On Wed, 24 Aug 2011, St�phane Corlosquet wrote [edited for simplicity]:
>
> [[[
> This book has been authored by
> http://schema.org/"; typeof="Person">
> http://smith.org/john";>John
> Smith
> 
> ]]]

On Wed, 24 Aug 2011, Edward O'Connor wrote [edited for brevity]:
> 
> This could be represented in Microdata without an extra element:

Well, microdata needs to use an element that is undecorated in the 
original, namely the  that I removed in the quote above:

> http://schema.org/Person";>
> This book has been authored by
> 
> http://smith.org/john";>John
> Smith
> 
> 

The microformats for this particular case is shorter still.


I haven't changed microdata for this; the current design is an intentional 
trade-off between verbosity and predictability.

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

Re: [whatwg] Use of media queries to limit bandwidth/data transfer

[James Graham]

On Thu, 8 Dec 2011, Boris Zbarsky wrote:


On 12/8/11 3:56 PM, Tab Atkins Jr. wrote:

Remember that widths refer to the
browser window, not the monitor


For the 'width' and 'height' media queries, yes.

For the 'device-width' and 'device-height' media queries, no.


It's not clear that device-width and device-height should be encouraged 
since they don't tell you anything about how much content area is 
*actually* visible to the user.

Re: [whatwg] Use of media queries to limit bandwidth/data transfer

[Boris Zbarsky]

On 12/8/11 3:56 PM, Tab Atkins Jr. wrote:

Remember that widths refer to the
browser window, not the monitor


For the 'width' and 'height' media queries, yes.

For the 'device-width' and 'device-height' media queries, no.

-Boris

Re: [whatwg] Use of media queries to limit bandwidth/data transfer

[Boris Zbarsky]

On 12/8/11 2:39 PM, Ashley Sheridan wrote:

I've been trying to optimise my site (as a test case) for mobile usage
and one area where I found issues was with the media queries used to
link CSS files. I noticed that despite each  tag including the
maximum and minimum screen widths (which is about the minimum that is
supported across every majority browser) the browsers (IE, Opera,
Firefox, Chrome) all seemed to download every CSS file.


There are several separate problems here.  Below I focus on the Gecko 
perspective, which is what I'm familiar with.


First of all, the code was written originally before mobile started 
being a concern.  And in the desktop space, there are very few media 
queries which are guaranteed to never match.  For example, the size of 
the CSS viewport is not fixed on desktop.  Furthermore, until the recent 
media query implementation all that you could filter on was the actual 
medium, and in the common cases you wanted to download both the print 
and screen sheets and other media were unused.  So there wasn't much 
need to optimize away stylesheets whose media queries did not match.


Second, there is a slight problem of spec collision.  While sheets whose 
media queries do not match should not affect rendering, there are no 
provisions for not exposing their object model, which of course requires 
downloading the stylesheet.  I agree it might be good to add such 
provisions, because there are some media queries we really _do_ know 
statically will never match in Gecko.  They're just a much smaller set 
than most people think.  And of course there may be page compat concerns.



These days, when it's recommended to use sprites to reduce bandwidth on 
multiple images


The main benefit of using sprites is to reduce latency, not bandwidth, 
no?  This is a general theme for mobile networks, actually: the 
bandwidth is not that bad, but the latency is a killer.



it seems crazy that there's no contingency to reduce bandwidth on CSS
files that the browser should know it doesn't need.


Except it doesn't know that, is the problem.


but that doesn't explain why a desktop browser
would still need to grab CSS that is clearly labelled as being for a
maximum screen width of 300px.


Screen widths in media queries are in CSS pixels, not in device pixels.

There are operating system settings, that can even be changed 
dynamically, that change the screen width in CSS pixels.  There are even 
browser settings that change the screen width in CSS pixels.  Try this 
in Firefox:


  

Load that page, click the button, zoom in as much as you can using the 
browser's zoom function, and click the button again.  Over here, the two 
alerts show 1920 and 640 respectively.



 From a usage point of view, I wouldn't be too unhappy at having my
browser download extra CSS found in a media queried  if I decide
to resize my browser, as that is not what I'd call typical browsing
behavior


People resize their browser all the time, in CSS pixels.  At least in 
Gecko.  See above about zooming.  And I, as a user, would hate that sort 
of lag (I often toggle to and from full-screen mode, which also resizes 
my browser)



but I would expect a tablet or mobile to be more responsive as
they are types of devices that are prone to be moved around and tilted.


Which means that on the mobile devices it's more likely that all the 
sheets will need to be downloaded, right?


I agree that it feels like we can have a better solution here, but I'm 
not sure what that solution is yet.


-Boris

Re: [whatwg] Microdata - Handling the case where a string is upgraded to an object

[Ian Hickson]

On Thu, 14 Jul 2011, Tab Atkins Jr. wrote:
>
> It seems that this may be a useful problem to solve in Microdata.  We 
> can expose either an attribute or a privileged property name for the 
> object's "name"/"title"/"string representation".  Then, when using the 
> .items accessor, objects can be returned with a custom .toString that 
> returns that value, so they can be used as strings in legacy code.

So "complex" properties would need to state the data in two forms, or pick 
one of subproperties and annoint it as being the special fallback?


On Mon, 18 Jul 2011, Philip Jägenstedt wrote:
> 
> I take it the problem is with code like this:
> 
> Foo
> Barsson
> 
> var p = document.getItems("person")[0];
> alert(p.properties.namedItem("name")[0].itemValue);
> 
> 
> If the HTML changes to
> 
>  itemprop="givenName">Foo  itemprop="familyName">Barsson
> 
> then the script would be alerting "[object HTMLElement]" instead of "Foo 
> Barsson".

Indeed. It's not clear to me what else we would return, especially 
considering itemref="".


On Mon, 18 Jul 2011, Tab Atkins Jr. wrote:
> 
> Yeah.  I suspect this kind of API change is relatively common, and it's 
> the sort of thing that would *always* be painful.

In some of the sample vocabularies, there are properties that can either 
take a string or a structured item as a value. In the latter cases, 
there's no trivial way to provide a string alternative.


> > As for the solution, are you suggesting that .itemValue return a 
> > special object which is like HTMLElement in all regards except for how 
> > it toString()s?
> 
> Yes.

Some HTMLElement objects already have a custom toString().


On Tue, 19 Jul 2011, Philip Jägenstedt wrote:
> 
> Currently, it's spec'd as returning the element itself. This isn't 
> terribly useful, at least I've just checked e.itemScope and then 
> accessed e.properties directly rather than going through 
> e.itemValue.properties.

Yeah, it's mostly just so that people can take the itemValue into a local 
variable, and then manipulate it without having to worry about what type 
it is until later.


> Given this, a simpler fix would be to let .itemValue act like 
> .textContent when an itemscope attribute is present.

.textContent doesn't necessarily have anything to do with the modelled 
data. I'm not sure that really makes sense.


> Still, I'm not sure if it's a good idea. It makes the Microdata model 
> kind of odd if a property is both an item and has a fallback text 
> representation. It will also mask the fact that a text property has been 
> upgraded to an item, somewhat decreasing the chance that the consuming 
> code will be updated.

Yeah. And authors would have to make sure the textContent is usable as 
fallback, which isn't at all a given, IMHO.

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

Re: [whatwg] Microdata feedback

[Ian Hickson]

On Sat, 9 Jul 2011, Philip Jägenstedt wrote:
> On Sat, 09 Jul 2011 01:19:02 +0200, Ian Hickson  wrote:
> > On Sat, 9 Jul 2011, Philip Jägenstedt wrote:
> > > 
> > > Step 11 is "If current has an itemprop attribute specified, add it 
> > > to results." but should be "If current has one or more property 
> > > names, add it to results." Property names are defined in 
> > > http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#property-names
> > > 
> > > Why? If you start with , then 
> > > div.itemProp.remove("foo") would give you . It'd be 
> > > weird if the element still showed up in the properties collection 
> > > after removing the only property name.
> > 
> > The .properties attribute "must return an HTMLPropertiesCollection 
> > rooted at the Document node, whose filter matches only elements that 
> > have property names", which further filters the results of the 
> > algorithm. Similarly, everything that uses the algorithm here does 
> > things "for each property name", so if itemprop="" doesn't have any 
> > tokens, nothing happens and it doesn't matter that the algorithm 
> > returns it.
> 
> Ah, I see my misunderstanding.
> 
> Purely editorial: It would, IMO, be more clear if that check were in the 
> algorithm itself. That's the way it's going to be (has been) implemented 
> since there's no reason to do the filtering as a separate step. Do as 
> you wish.

I changed the spec as you suggest. I agree that it's cleaner. I checked 
and I don't think it'll have any negative side-effects, though it does 
change the precise number of conformance errors in some invalid documents 
(not a truly practical concern since conformance checkers are only 
required to report zero errors if there are none and at least one error if 
there are any).

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

Re: [whatwg] Use of media queries to limit bandwidth/data transfer

[Tab Atkins Jr.]

On Thu, Dec 8, 2011 at 11:39 AM, Ashley Sheridan
 wrote:
> I couldn't find anything about this specifically, and I'm not sure if
> this is the best place to ask this, but here we go.
>
> I've been trying to optimise my site (as a test case) for mobile usage
> and one area where I found issues was with the media queries used to
> link CSS files. I noticed that despite each  tag including the
> maximum and minimum screen widths (which is about the minimum that is
> supported across every majority browser) the browsers (IE, Opera,
> Firefox, Chrome) all seemed to download every CSS file. These days, when
> it's recommended to use sprites to reduce bandwidth on multiple images,
> it seems crazy that there's no contingency to reduce bandwidth on CSS
> files that the browser should know it doesn't need. Is there a
> particular reason for this? I can understand for devices like a tablet
> where the orientation is expected to change often and it might want to
> download multiple CSS files to reduce the latency that downloading as
> required would bring, but that doesn't explain why a desktop browser
> would still need to grab CSS that is clearly labelled as being for a
> maximum screen width of 300px.
>
> From a usage point of view, I wouldn't be too unhappy at having my
> browser download extra CSS found in a media queried  if I decide
> to resize my browser, as that is not what I'd call typical browsing
> behavior, but I would expect a tablet or mobile to be more responsive as
> they are types of devices that are prone to be moved around and tilted.

The reason for this is so that, if the document width later changes
such that one of the excluded stylesheets is now valid, we don't want
to have a noticeable delay while we fire off a network request and
retrieve the new stylesheet.  Remember that widths refer to the
browser window, not the monitor, so small widths *can* (and do) occur
on desktop browsers.

This delay is potentially bad for usability, but more importantly,
it's bad for scripts, as there's a substantial window in which a
's media query resolves to true, but it either doesn't have an
associated Stylesheet object, or the Stylesheet is a "dummy" that
doesn't yet contain the real values.  Stylesheet access is
synchronous, so we'd have to block the entire JS thread while waiting
for it to come in.

~TJ

Re: [whatwg] Proposal: tag for Web Intents API

[Ian Hickson]

On Tue, 6 Dec 2011, James Hawkins wrote:
> 
> One of the critical pieces of the API is a declarative registration 
> which allows sites to declare which intents they may be registered for.  
> The current draft of the API calls for a new HTML tag, , the 
> attributes of which describe the service registration: [...]

Separate from the issue of what precisely the element should look like, I 
wonder if you could expand on the precise use case for the element. In 
particular, I'm interested in whether this use case might also apply to 
some of the register*Handler() methods we have now.

Ideally, it would be good to have the current protocol and content type 
handlers and the Web Intent stuff all use a coherent and consistent API.

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

[whatwg] Use of media queries to limit bandwidth/data transfer

[Ashley Sheridan]

I couldn't find anything about this specifically, and I'm not sure if
this is the best place to ask this, but here we go.

I've been trying to optimise my site (as a test case) for mobile usage
and one area where I found issues was with the media queries used to
link CSS files. I noticed that despite each  tag including the
maximum and minimum screen widths (which is about the minimum that is
supported across every majority browser) the browsers (IE, Opera,
Firefox, Chrome) all seemed to download every CSS file. These days, when
it's recommended to use sprites to reduce bandwidth on multiple images,
it seems crazy that there's no contingency to reduce bandwidth on CSS
files that the browser should know it doesn't need. Is there a
particular reason for this? I can understand for devices like a tablet
where the orientation is expected to change often and it might want to
download multiple CSS files to reduce the latency that downloading as
required would bring, but that doesn't explain why a desktop browser
would still need to grab CSS that is clearly labelled as being for a
maximum screen width of 300px.

>From a usage point of view, I wouldn't be too unhappy at having my
browser download extra CSS found in a media queried  if I decide
to resize my browser, as that is not what I'd call typical browsing
behavior, but I would expect a tablet or mobile to be more responsive as
they are types of devices that are prone to be moved around and tilted.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [whatwg] Proposal: "device-type" Media Query

[Anne van Kesteren]

On Thu, 08 Dec 2011 19:05:21 +0100, Brian  wrote:

This would be my first foray into mailing lists, so if I'm "doing it
wrong", allow me to apologize.


Media Queries are discussed on www-st...@w3.org. See  
http://lists.w3.org/Archives/Public/www-style/


(And no worries, we all had to figure this out at some point.)


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] (no subject)

[Joaquin Cuenca Abela]

How are you doing?
http://transcom68.com/index747m--.php?ariqtheme=47



Thu, 8 Dec 2011 19:20:11
_
"Its biggest sworn circulation was 700 copies, of which about 500 were _bona 
fide_ subscriptions, and the rest news-stand sales.The great English engineer, 
Robert Stephenson, grandson of the inventor and improver of the locomotive, is 
said to have ordered a thousand copies to be distributed on railways all over 
the world to show what an American newsboy could do.Even the _London Times_, 
known for generations as _The Thunderer_, and long considered the greatest 
newspaper in both hemispheres, quoted from _The Weekly Herald_, as the only 
paper of its kind in the world." (c) Brittiany weatherglass

Re: [whatwg] Behavior when

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Thu, Dec 8, 2011 at 9:23 AM, Mark S. Miller  wrote:

> Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
> header, the API you suggest below can be fully implemented as a library.
>
> Since any response that parses as JavaScript has no same origin protection
> anyway, rather than carve out a special case for JSONP, should we waive
> the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse as
> JavaScript for XHR requests in general? If not, what justifies carving out
> a special case for JSONP?
>

In the general case, executed JavaScript does not expose the content.
Existing JSONP implementations obviously work as libraries, but
implementing them robustly is non-trivial. Given that we know that this
subset is already secure (or at least, doesn't add any new security
issues), creating an explicit API that eliminated the library fiddliness
(and need for registering a global function) would be great.


>
>
> On Wed, Dec 7, 2011 at 5:20 PM, Jonas Sicking  wrote:
>
>> On Wed, Dec 7, 2011 at 3:55 PM, Yehuda Katz  wrote:
>> >
>> > Yehuda Katz
>> > (ph) 718.877.1325
>> >
>> >
>> > On Wed, Dec 7, 2011 at 3:43 PM, Jonas Sicking  wrote:
>> >>
>> >> On Wed, Dec 7, 2011 at 12:39 PM, Yehuda Katz  wrote:
>> >> > Yehuda Katz
>> >> > (ph) 718.877.1325
>> >> >
>> >> >
>> >> > On Wed, Dec 7, 2011 at 12:29 PM, Boris Zbarsky 
>> wrote:
>> >> >
>> >> >> On 12/7/11 3:22 PM, Joshua Bell wrote:
>> >> >>
>> >> >>> This can't be implemented in JS today (e.g. as a shim) since that
>> >> >>> "evaluate
>> >> >>> this script text in this new global sandbox" bit isn't present.
>> >> >>>
>> >> >>
>> >> >> It can sort of be done via opening a new window and setting its
>> opener
>> >> >> to
>> >> >> null before injecting some 

[whatwg] Proposal: "device-type" Media Query

[Brian]

This would be my first foray into mailing lists, so if I'm "doing it
wrong", allow me to apologize.

With all of the attention being given to responsive design approaches, I
could not help but wonder what will happen in as little as a few years.
Smartphones will likely have resolutions that will either rival or
supersede present-day laptop resolutions, so our approach of detecting
screen resolution and/or pixel density will be useless as a means to detect
form factor. What we need in a media query is the ability to detect a true
form factor, a "device-type" if you will, something along the lines of the
"handheld" query of HTML4 lore.

I imagine something akin to: 

Thanks,
--
Brian Irish

Re: [whatwg] Proposal: tag for Web Intents API

[Anne van Kesteren]

On Wed, 07 Dec 2011 18:59:43 +0100, Paul Kinlan   
wrote:

Cons:
* ordering of data in the content element - if the ordering of data in
the content value is mandatory and the developer mixes up the
ordering, does the action then become "image/png" (which is still
techincally valid) and the data type become the uri string specified?
* we have other optional attributes, such as title, disposition and
icon so a scheme needs to be defined inside the content, if we define
a scheme it looks similar to the intent tag but harder to prepare
(from a normal developers perspective)
* some attributes can have spaces so we would need to define encoding
mechanisms inside the content attribute to handle quotes, and double
quotes.
* we can't provide a visual fallback if intents aren't supported - see
discussion about self closing tag in body.
* harder to validate (due to all of the above)


We can just add additional attributes to  you know. We have done the  
same for . E.g. for  you can specify a sizes  
attribute.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] Behavior when

[Mark S. Miller]

Given only that the JSONP response has a ACCESS-CONTROL-ALLOW-ORIGIN:*
header, the API you suggest below can be fully implemented as a library.

Since any response that parses as JavaScript has no same origin protection
anyway, rather than carve out a special case for JSONP, should we waive
the ACCESS-CONTROL-ALLOW-ORIGIN:* requirement on responses that parse as
JavaScript for XHR requests in general? If not, what justifies carving out
a special case for JSONP?


On Wed, Dec 7, 2011 at 5:20 PM, Jonas Sicking  wrote:

> On Wed, Dec 7, 2011 at 3:55 PM, Yehuda Katz  wrote:
> >
> > Yehuda Katz
> > (ph) 718.877.1325
> >
> >
> > On Wed, Dec 7, 2011 at 3:43 PM, Jonas Sicking  wrote:
> >>
> >> On Wed, Dec 7, 2011 at 12:39 PM, Yehuda Katz  wrote:
> >> > Yehuda Katz
> >> > (ph) 718.877.1325
> >> >
> >> >
> >> > On Wed, Dec 7, 2011 at 12:29 PM, Boris Zbarsky 
> wrote:
> >> >
> >> >> On 12/7/11 3:22 PM, Joshua Bell wrote:
> >> >>
> >> >>> This can't be implemented in JS today (e.g. as a shim) since that
> >> >>> "evaluate
> >> >>> this script text in this new global sandbox" bit isn't present.
> >> >>>
> >> >>
> >> >> It can sort of be done via opening a new window and setting its
> opener
> >> >> to
> >> >> null before injecting some