Re: [whatwg] Installable web apps
On Mon, Jun 14, 2010 at 7:27 AM, Anne van Kesteren wrote:
> On Thu, 27 May 2010 18:22:03 +0200, Aaron Boodman wrote:
>>
>> On Thu, May 27, 2010 at 5:09 AM, Lachlan Hunt
>> wrote:
>>>
>>>
>>
>> You're right -- that one does exist already within the page. And it is
>> a shame to waste these existing features.
>>
>> The more I think about it, the more I start to agree that just using
>> the and tags we already have (with perhaps one addition
>> for permissions), could work.
>>
>> Let me think about it some more.
>
> I think if we do more things it would make more sense to build them on top
> of rather than creating some new kind of JSON-based format
> that needs to be separately fetched.
Reviving ancient thread...
We are still interested in adding a lightweight concept of
'installation' to Chromium and Google Chrome that is separate from the
crx format. The attributes of an application that we like at the
moment are:
- a name
- a description
- a launch url
- icons of various sizes
- a set of permissions, such as geolocation and notifications
- a set of associated URLs (we would use this in Chromium to make
better decisions about how to group processes, and potentially how to
handle navigation)
To get a feel for the different approaches and tradeoffs, I've
implemented a prototype of this using the two of the approaches that
were discussed in this thread:
1. Embed metadata in the page, building off the existing support for,
eg, :
http://games.com/pacman";>
2. Link to a separate metadata document:
// application-definition.json
{
"name": "Pacman",
"description": "The arcade classic",
"launch_url": "http://games.com/pacman";,
"icons": [
{
"url": "48.png",
"width": 48,
"height": 48
},
{
"url": "128.png",
"width": 128,
"height": 128
}
],
"permissions": [
{ "name": "geolocation" },
{ "name": "notifications" },
... etc ...
],
"urls": [
"pacman/"
]
}
In both cases, there would also be an associated navigator API:
void navigator.installApplication();
bool navigator.isInstalled;
I did not pursue adding the application definition to the existing app
cache manifest format. I discussed that with Chromium's resident
appcache expert and he was against it because he felt that the two
things were really completely different features and preferred keeping
them decoupled.
As I see it, here are the advantages of the two approaches:
1:
- a bit simpler
- builds off the existing features in the platform
2:
- DRY-er (doesn't repeat the same information on multiple pages of the
application)
- Easier for third-party agents (eg search engines) to consume
(doesn't require an HTML parser)
- The browser doesn't have to load a page to consume
Based on this, I'm liking #2 better as a path forward and am going to
push to get an implementation of this working in Chromium.
Are there any other vendors interested in doing something similar? If
so, I'd like to hash out the details so we end up with
interoperability.
Thanks,
- a
Re: [whatwg] required attribute in label
On Sat, Aug 21, 2010 at 6:18 PM, Brenton Strine wrote:
>>
>
> and
>
>>
>
> are effective, but then again this would be too:
>
> ...*
>
> It just seems a shame that we have this neat attribute that indicates
> required controls, but we can't actually use it to change the
> presentation adding additional code.
Presentation issues should by addressed by CSS, not by HTML.
Actually, Diego's suggestion:
label + input[required] + span:after { content: " * "; }
Seems to be the right approach here (with current CSS selectors).
I'm not considering IE's issue with attribute selectors because your
original proposal (label[required]) would encounter the same problems.
What sense would have to mark a *label* as required? @required on
is semantically wrong. And HTML should not compromise
semantics only for presentation purposes.
On a side note, keep in mind that there have been several proposals on
the CSS lists for "reversed" selectors (ie: selecting elements based
on what they contain rather than what contains them). So hopefully we
might have something like label:has(+ input[required]):after {
content: " *"; } in the future.
Just my thoughts.
Regards,
Eduard Pascual
[whatwg] [Selectors4] Linked Elements, was: required attribute in label
Someone on wha...@whatwg.org:
> This question is sort of CSS related, but I think it's worth bringing up
> here, assuming it hasn't already been discussed.
I’m cross-posting to www-style, please follow-up there.
> [required]:after {content:"*";}
>
> Name
>
If we ignore the possibility of anonymous child elements ‘::before’ and
‘::after’ for replaced elements, this use case is somewhat more likely to be
solved in the not too distant future when the code looks more like this:
There have been many proposals to add a selector that matches elements based on
their children.
input[required] < label /* what many proponents suggest first */
label:has(input[required]) /* previous draft proposal */
label:matches(input[required]) /* the latest favored syntax, I think */
What you are (not really) asking for would need something more complex.
input[required] = label
input[required][id>=] ~ label[for<=] /* ~ requires them to be siblings */
input[required][id=#1] ~ label[for=#1]
input[required][id#=] ~ label[for#=]
input[required]:target ~ label:source
label[for]:links(input[required][id])
label:links(input[required])
Something like that. Remember that the rightmost element is the one the style
ruleset is applied to, therefore ‘label’ needs to come last or must have
‘input’ inside a pseudo class (or pseudo attribute).
This is probably not easy or not possible to implement efficiently. In my
opinion Selectors (and some CSS modules) should have profiles associated with
them for different types of implementations: e.g. interactive, real-time user
agents and non-interactive ones that can take their time to layout a page.
Re: [whatwg] required attribute in label
> and > are effective, but then again this would be too: ...* It just seems a shame that we have this neat attribute that indicates required controls, but we can't actually use it to change the presentation adding additional code. Brenton
Re: [whatwg] Fullscreen feedback
On Sat, Aug 21, 2010 at 2:00 AM, Robert O'Callahan wrote: > On Sat, Aug 21, 2010 at 5:21 PM, Adam Barth wrote: >> How is going fullscreen different from opening a popup window? > > That depends on how the UA chooses to handle it. But this proposed > fullscreen API is based on the idea that the fullscreen content "takes over" > the toplevel browsing context to which it belongs. (The content is styled to > fill the IFRAME, and the IFRAME element is styled to fill the parent > document's viewport.) That does seem dangerous if the location bar still displays the URL of the top-level browsing context because it violates the constraint principle of display delegation. This doesn't seem like a good model for full-screen. I would think the model of re-parenting the content to a popup window that fills the entire screen would be a better model. In that case, we'd want to disable or limit keyboard input to prevent full-screen phishing, similar to how Flash protects it's full-screen mode. Adam
Re: [whatwg] required attribute in label
On Fri, Aug 20, 2010 at 11:33 PM, WhatWg wrote: > However, it seems that since input is an empty element, the content cannot > be added after. Right; s don't have children. (In some actual implementations, they just automatically hide their children from the rest of the DOM.) ~TJ
Re: [whatwg] More YouTube response
Hardly an expert in this field, but wouldn't implementing media tags (video and audio) a tad like websockets be a good idea. Using the tag should add a special header that says it can upgrade conneciton to something like "media" which constantly lets client have duplex conversation with the server, which can give all sorts of information about the client side like desired bitrate, desired camera, player state(pause, resume,etc) which will have reasonable default behaviour, but can be set or taken over by javascript if needed. On the other hand, if the server end was not happy with the upgrade request, the browser cann fall back to current behaviour just my two cents -- Laxminarayan Kamath Ammembal http://lankerisms.blogspot.com (+91) 9945036093
Re: [whatwg] required attribute in label
This could be another way to solve the same problem:
label + input[required] + span:after { content: " * "; }
Name
However, the above does not work on IE6 (attribute selectors).
So the id/class suggested by Chris is actually the most cross-browser
solution.
Diego
On Sat, Aug 21, 2010 at 3:26 PM, Chris Cressman wrote:
> > Why not make "required" an acceptable attribute for the label element?
>
> The class or title attribute can solve your problem:
>
>
> label.required:after {content:"*"}
>
>
> label[title~="required"]:after {content:"*"}
>
Re: [whatwg] required attribute in label
> Why not make "required" an acceptable attribute for the label element?
The class or title attribute can solve your problem:
label.required:after {content:"*"}
label[title~="required"]:after {content:"*"}
Re: [whatwg] question about canvas globalCompositeOperation
Sorry, forget about this question. I have managed to get it working after all. Apologies, Silvia. On Sat, Aug 21, 2010 at 5:54 PM, Silvia Pfeiffer wrote: > Hi all, > > I've tried to work with the globalCompositeOperation [1] over the last days > for a particular use case where I am trying to use a gradient to merge with > a canvas as a mask. I now wonder if the globalCompositeOperation is indeed > meant to be used this way and what transparency means. > > For example, "source-in" is defined as: > "A in B": Display the source image wherever both the source image and > destination image are opaque. Display transparency elsewhere. > > What about partial transparency? I would expect the use of the canvas > bitmap B as a mask for the object or image A, where A becomes partially > transparent where-ever B is partially transparent. As it stands, browsers do > not implement it this way - only completely transparent pixels will create > transparency in A, which means when using a gradient that nothing become > partially transparent - it's either there or gone. > > Should partial transparency in B not be dealt with as partial transparency > in the resulting display, too? > > Apologies if this has been dealt with before. I'm looking at it with video > as the input medium, i.e. through drawImage(), trying to make it partially > transparent. > > Cheers, > Silvia. > > > [1] > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-globalcompositeoperation > >
Re: [whatwg] Fullscreen feedback
On Sat, Aug 21, 2010 at 5:21 PM, Adam Barth wrote: > How is going fullscreen different from opening a popup window? > That depends on how the UA chooses to handle it. But this proposed fullscreen API is based on the idea that the fullscreen content "takes over" the toplevel browsing context to which it belongs. (The content is styled to fill the IFRAME, and the IFRAME element is styled to fill the parent document's viewport.) Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
[whatwg] question about canvas globalCompositeOperation
Hi all, I've tried to work with the globalCompositeOperation [1] over the last days for a particular use case where I am trying to use a gradient to merge with a canvas as a mask. I now wonder if the globalCompositeOperation is indeed meant to be used this way and what transparency means. For example, "source-in" is defined as: "A in B": Display the source image wherever both the source image and destination image are opaque. Display transparency elsewhere. What about partial transparency? I would expect the use of the canvas bitmap B as a mask for the object or image A, where A becomes partially transparent where-ever B is partially transparent. As it stands, browsers do not implement it this way - only completely transparent pixels will create transparency in A, which means when using a gradient that nothing become partially transparent - it's either there or gone. Should partial transparency in B not be dealt with as partial transparency in the resulting display, too? Apologies if this has been dealt with before. I'm looking at it with video as the input medium, i.e. through drawImage(), trying to make it partially transparent. Cheers, Silvia. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-globalcompositeoperation
