[whatwg] Getting started with the W3C AR Community Group

[Rob Manson]

Hi all,

the W3C AR Community Group has been established and is now open for
people to join.  Great work on proposing the group Ya Knygar.

Now I think it would be good to make some clear plans about what the
goals of the group are and what the scope of our activities are.

>From my perspective this would simply be:

"The development of a Web Standards based model 
for Augmented Reality"

If you have a proposal for an alternate goal/scope then please submit it
and we can run a poll to select what the group runs with.

Also, I don't think this group is going to work if we just automatically
make everyone who joins a co-chair 8)  At the moment everyone who has
signed up has been made chair.  I'd rather see us first establish the
goals for the group, then run a poll to decide how the group will be
managed and who the chair/s are.  We don't need to be too formal...but a
little structure would be good I think.

We will also need to clearly define how this groups is different from
the existing AR related groups that have formed already.  I think the
goal I've proposed above does that (e.g. focus solely on Web Based
AR) ...but more discussion is obviously required.

So, please join the group and get involved in this important discussion.

http://www.w3.org/community/ar/

There's a lot happening and a lot of APIs that will directly impact the
future of a Web Based AR are being defined right now. So now is the
perfect time to get this up and running.

roBman

PS: I've cc'd all the related groups I'm involved in to encourage anyone
with a stake in related technologies and APIs to join this group.

PPS: I've also cc'd in the W3C Community people as I think this
discussion is as much about Community Group process as it is about the
content of our group.

Re: [whatwg] Need clarification on DOM exceptions thrown by canvas 2D drawImage

[Justin Novosad]

Hi Ian,

I just wanted to revive this thread because the issue of what to do
with source rectangles that are partially outside of the source image
in calls to canvas drawImage is still not completely resolved.

The discussion continued here: https://bugs.webkit.org/show_bug.cgi?id=65709
It is now spun-off into a separate issue:
https://bugs.webkit.org/show_bug.cgi?id=66574

In the discussion for 65709, we think we figured out what the right
thing to do is. Nonetheless, it would probably be best if the matter
could be settled definitively and formally in the specification.

Thanks,

-Justin

[whatwg] Looking for volunteer for the PDF versions

[Ian Hickson]

On Fri, 19 Aug 2011, Alexandre Morgaut wrote:
>
> Is it just me or is the WHATWG Blog out of service ?
> 
> http://blog.whatwg.org/

It seems the daily PDF generation of the spec is exceeding the memory 
limits I have put on the server. I could just increase the limits, but in 
general I prefer to move background processes like this onto other 
machines. If anyone is interested in being responsible for updating the 
PDF files, please let me know. The ideal solution would be a CGI script on 
a box somewhere that the whatwg.org server could occasionally send a POST 
request to, which would then generate the PDFs and send them back for 
uploading to the Web server.

If anyone is interested in doing this please ping me on IRC.

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

Re: [whatwg] [editing] Additional miscellaneous commands

[Aryeh Gregor]

2011/8/18 Alfonso Martínez de Lizarrondo :
> Showing all whitespace would be the most complete solution, but if the rest
> of browsers could behave like Opera and handle this, that would be enough
> for most of the people:
>
> br:before {content: "\B6";}

That doesn't sound like a great solution, since it doesn't work for
line breaks created by things like .  There's no visible difference
between foobar and foobar, so it's confusing
to have them behave differently.  I'm not surprised that browsers
don't agree here, though, because  is pretty magical and
underspecified.

> on the other side it's clear that besides the .execCommand a good Editing
> spec should state or hint about other features that the browsers must
> implement to behave properly (like showing the caret so the user knows where
> he's typing,  enable the user to select parts of the content,...). These
> might look trivial, but iOS5 seems to be the first mobile browser that will
> behave good enough so that both CKEditor and TinyMCE will enable the support
> for it (check the comments in
> http://code.google.com/p/android/issues/detail?id=8253 about the Android
> browser)
> A browser that provides a perfect implementation of all the execCommands but
> doesn't allow the user to type or select is worthless for editing.

There's not much need to specify things that are completely obvious.
If Android's browser doesn't support contenteditable, that means they
haven't gotten around to it yet, and writing in a standard that they
have to do it isn't going to make them do it any faster.  Standards
are necessary to allow implementers to implement the same thing when
they want to implement it at all, not to make them implement something
that they aren't interested in right now.

Re: [whatwg] Problem with the blog

[Etienne Levesque Guitard]

Looks like it's you. I just loaded the page on my Android.

Etienne
On 2011-08-19 11:09 AM, "Alexandre Morgaut" 
wrote:
> Is it just me or is the WHATWG Blog out of service ?
>
> http://blog.whatwg.org/
>
>
>
>
> Alexandre Morgaut
> Product Manager
>
> 4D SAS
> 60, rue d'Alsace
> 92110 Clichy
> France
>
> Standard : +33 1 40 87 92 00
> Email : alexandre.morg...@4d.com
> Web : www.4D.com
>
>

Re: [whatwg] Problem with the blog

[Alexandre Morgaut]

Sorry 

It looks to be back...


On 19 août 2011, at 17:09, Alexandre Morgaut wrote:

> Is it just me or is the WHATWG Blog out of service ?
> 
> http://blog.whatwg.org/
> 
> 
> 
> 
> Alexandre Morgaut
> Product Manager
> 
> 4D SAS
> 60, rue d'Alsace
> 92110 Clichy
> France
> 
> Standard : +33 1 40 87 92 00
> Email :alexandre.morg...@4d.com
> Web :  www.4D.com
> 
> 

[whatwg] Problem with the blog

[Alexandre Morgaut]

Is it just me or is the WHATWG Blog out of service ?

http://blog.whatwg.org/




Alexandre Morgaut
Product Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :alexandre.morg...@4d.com
Web :  www.4D.com

Re: [whatwg] [editing] Additional miscellaneous commands

[Alfonso Martínez de Lizarrondo]

2011/8/19 Bjartur Thorlacius 

> Şann fim 18.ágú 2011 21:05, skrifaği Alfonso Martínez de Lizarrondo:
>
>  Now if someone had some bright idea to enable finding in the hidden text
>> that would be perfect, but the view source workaround is good enough for
>> the
>> moment.
>>
>>  That seems to be of general utility. I recommend sending feature request
> to implementors.
>
>
>  That's just CSS and I'm not sure if it should be present in this spec, but
>> on the other side it's clear that besides the .execCommand a good Editing
>> spec should state or hint about other features that the browsers must
>> implement to behave properly (like showing the caret so the user knows
>> where
>> he's typing,  enable the user to select parts of the content,...). These
>> might look trivial, but iOS5 seems to be the first mobile browser that
>> will
>> behave good enough so that both CKEditor and TinyMCE will enable the
>> support
>> for it (check the comments in
>> http://code.google.com/p/**android/issues/detail?id=8253about
>>  the Android
>> browser)
>>
> As long as overspecification is avoided (care must be taken to allow e.g.
> caret(s) to be hidden when another top-level window is focused, etc).
>
>
>  A browser that provides a perfect implementation of all the execCommands
>> but
>> doesn't allow the user to type or select is worthless for editing.
>>
> Then requiring implementations to allow users to select and replace any
> substring consisting of a sequence of whole characters (i.e. characters
> represented by a single glyph) and insert text of their own at any character
> boundaries seems reasonable. I don't see why mandating carets is needed.
> Should users not be allowed to edit editable content using structural and/or
> aural editors?
>

If the word "caret" is a problem you can suggest anything else to satisfy
you, as I stated the goal is that the user is able to easily change the
contents of the editable element, I'm not worried about the exact wording.