Re: [whatwg] [editing] Additional miscellaneous commands
2011/8/19 Bjartur Thorlacius svartma...@gmail.com Ş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=8253http://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.
[whatwg] Problem with the blog
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
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
Re: [whatwg] Problem with the blog
Looks like it's you. I just loaded the page on my Android. Etienne On 2011-08-19 11:09 AM, Alexandre Morgaut alexandre.morg...@4d.com 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] [editing] Additional miscellaneous commands
2011/8/18 Alfonso Martínez de Lizarrondo aml...@gmail.com: 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 p. There's no visible difference between divfoo/divdivbar/div and foobrbar, so it's confusing to have them behave differently. I'm not surprised that browsers don't agree here, though, because br 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.
[whatwg] Looking for volunteer for the PDF versions
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] Need clarification on DOM exceptions thrown by canvas 2D drawImage
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] Getting started with the W3C AR Community Group
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.