Re: [whatwg] Media elements statistics

[Silvia Pfeiffer]

On Fri, May 6, 2011 at 3:04 AM, Steve Lacey  wrote:
>
>
> On Thu, May 5, 2011 at 2:54 AM, Jeroen Wijering 
> wrote:
>>
>> Hey Steve,
>>
>> This looks great; would be a really useful set of data for video players /
>> publishers. Since none of the metrics have a time component, developers can
>> sample the data over the window / at the frequency they prefer.
>>
>> Would jitter be calculated over decodedFrames or
>> decodedFrames+droppedFrames? In the first case, jitter is a more granular
>> metric for measuring exact presentation performance. In the latter case,
>> jitter can serve as a single metric for tracking processing power (simple!).
>> In either case, it's fairly straightforward to calculate towards the other
>> metric.
>
> Actually, I would expect presentedFrames + droppedFrames would be used. This
> implies all decoded frames that were supposed to be presented.


Do we also expose to the JS developer how many frames we actually
requested, so we can calculate rates?

Silvia.

Re: [whatwg] Full Screen API Feedback

[Maciej Stachowiak]

On May 13, 2011, at 10:01 PM, Robert O'Callahan wrote:

> On Fri, May 13, 2011 at 8:52 PM, Maciej Stachowiak  wrote:
> Limited or no keyboard input also greatly mitigates the risk of a full OS UI 
> spoofing attack. I think there are better ways to address this than prompting 
> the user. For example, for apps requesting full keyboard access, there could 
> be an always-visible onscreen indicator that is not easily covered up. This 
> does not necessarily have to be ugly, or distracting in a game context.
> 
> Can you elaborate on that? I'm having trouble thinking of a generic onscreen 
> indicator that would meet that goal.

For example, a distinctive bar across the top of the screen with a button that 
clearly takes the user out of fullscreen. It could look similar to the menu bar 
found on Mac OS X or the status bar found on iOS. It could fade after some 
period of no user interaction, if that would be helpful for cases. Another 
possibility is a small square in the corner with a close box appearance.

It's true that this would prevent really true full screen for a game. However, 
it would be more effective at mitigating full OS UI simulation attacks than a 
confirmation prompt and would be less likely to confuse the user.

I believe also that for a Web app the user has explicitly chosen to "install", 
as with the Chrome Web Store, or for the no-keyboard / limited-keyboard case, 
these kinds of tricks are not even be necessary.

I think not having a full keyboard input mode at all is an option that should 
be seriously considered. Probably a very small set of keys is sufficient for 
games.


> 
> Another possibility is to have the indicator appear on mouse move.
> 
> That's fine for video, but not for anything interactive. Do you have in mind 
> a generic onscreen indicator that would work well for, say, Quake?


Regards,
Maciej

Re: [whatwg] CORS requests for image and video elements

[Kenneth Russell]

On Tue, May 17, 2011 at 6:11 PM, Ian Hickson  wrote:
> On Tue, 17 May 2011, Kenneth Russell wrote:
>>
>> Last week, a proof of concept of a previously theoretical timing attack
>> against WebGL was published which allows theft of cross-domain images'
>> content.
>>
>> To address this vulnerability it appears to be necessary to ban the use
>> of cross-domain images and videos in WebGL. Unfortunately, doing so will
>> prevent entire classes of applications from being written, and break a
>> not insignificant percentage of current applications.
>>
>> We would like to use CORS to solve this problem; if the server grants
>> access to the image or video, WebGL can use it. Initial discussions with
>> image hosting services have been positive, and it seems that CORS
>> support could be enabled fairly quickly. Many such services already
>> support other access control mechanisms such as Flash's crossdomain.xml.
>> Unfortunately, experimentation indicates that it is not possible to
>> simply send CORS' Origin header with every HTTP GET request for images;
>> some servers do not behave properly when this is done.
>>
>> We would like to propose adding a new Boolean property, useCORS, to
>> HTMLImageElement and HTMLMediaElement, defaulting to false. If set to
>> true, then HTTP requests sent for these elements will set the Origin
>> header from the page's URL. If the Access-Control-Allow-Origin header in
>> the response grants access, then the content's origin will be treated as
>> the same as the page's.
>
> On Tue, 17 May 2011, Jonas Sicking wrote:
>>
>> Does setting "useCORS" make the CORS implementation execute with the
>> "supports credentials" flag set to true or false?
>>
>> When set to true, the request to the server will contain the normal
>> cookies which the user has set for that domain. However, the response
>> from the server will have to contain "Access-Control-Allow-Origin:
>> ". In particular "Access-Control-Allow-Origin:*" will not be
>> treated as a valid response.
>>
>> If the "supports credentials" flag is set to false, the request will be
>> made without cookies, and the server may respond with either
>> "Access-Control-Allow-Origin:*" or "Access-Control-Allow-Origin:
>> ".
>>
>> I propose that the latter mode is used as it will make servers easier to
>> configure as they can just add a static header to all their responses.
>
> On Tue, 17 May 2011, Glenn Maynard wrote:
>>
>> This could be specified, eg.  without credentials and > cors="credentials"> with.  I don't know if there are use cases to
>> justify it.
>
> On Tue, 17 May 2011, Kenneth Russell wrote:
>>
>> In general I think we need to enable as close behavior to the normal
>> image fetching code path as possible. For example, a mashup might
>> require you to be logged in to a site in order to display thumbnails of
>> movie trailers. If normal image fetches send cookies, then it has to be
>> possible to send them when doing a CORS request. I like the idea of > cors> vs. .
>
> I've added a content attribute to , , and  that makes
> the image or media resource be fetched with CORS And have the origin of
> the page if CORS succeeded.
>
> The attribute is "cross-origin" and it has two allowed values,
> "use-credentials" and "anonymous". The latter is the default, so you can
> just say .
>
> This is only a first draft, I'm not sure it's perfect. In particular,
> right now cross-origin media is not allowed at all without this attribute
> (this is not a new change, but I'm not sure it's what implementations do).
> Also, right now as specced if you give a local URL that redirects to a
> remote URL, I don't have CORS kick in, even if you specified cross-origin.
> (This is mostly an editorial thing, I'm going to wait for Anne to get back
> and then see if he can help me out with some editorial changes to CORS to
> make it easier to make that work generally.)
>
> Implementation and author experience feedback would be very welcome on
> this.

Thanks very much for your prompt attention. This sounds like a great
first step. I'll personally try to implement this in WebKit ASAP, and
encourage other browser vendors who are members of the WebGL working
group to do so as well and provide feedback.

> On Tue, 17 May 2011, Kenneth Russell wrote:
>>
>> Perhaps an API could also be added to find out whether the server
>> granted CORS access to the resulting media, though this is less
>> important. (Note that the canvas element does not have an explicit API
>> for querying the origin-clean flag.)
>
> I haven't exposed this. You can work around it by trying to use the image
> in a canvas, then rereading the canvas, and seeing if you get a security
> error. If there are compelling use cases for that I'd be happy to add an
> API to handle this feature to the DOM though.

That sounds fine.

-Ken

> --
> Ian Hickson               U+1047E                )\._.,--,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are imp

Re: [whatwg] CORS requests for image and video elements

[Ian Hickson]

On Tue, 17 May 2011, Kenneth Russell wrote:
>
> Last week, a proof of concept of a previously theoretical timing attack 
> against WebGL was published which allows theft of cross-domain images' 
> content.
> 
> To address this vulnerability it appears to be necessary to ban the use 
> of cross-domain images and videos in WebGL. Unfortunately, doing so will 
> prevent entire classes of applications from being written, and break a 
> not insignificant percentage of current applications.
> 
> We would like to use CORS to solve this problem; if the server grants 
> access to the image or video, WebGL can use it. Initial discussions with 
> image hosting services have been positive, and it seems that CORS 
> support could be enabled fairly quickly. Many such services already 
> support other access control mechanisms such as Flash's crossdomain.xml.
> Unfortunately, experimentation indicates that it is not possible to 
> simply send CORS' Origin header with every HTTP GET request for images; 
> some servers do not behave properly when this is done.
> 
> We would like to propose adding a new Boolean property, useCORS, to 
> HTMLImageElement and HTMLMediaElement, defaulting to false. If set to 
> true, then HTTP requests sent for these elements will set the Origin 
> header from the page's URL. If the Access-Control-Allow-Origin header in 
> the response grants access, then the content's origin will be treated as 
> the same as the page's.

On Tue, 17 May 2011, Jonas Sicking wrote:
> 
> Does setting "useCORS" make the CORS implementation execute with the 
> "supports credentials" flag set to true or false?
> 
> When set to true, the request to the server will contain the normal 
> cookies which the user has set for that domain. However, the response 
> from the server will have to contain "Access-Control-Allow-Origin: 
> ". In particular "Access-Control-Allow-Origin:*" will not be 
> treated as a valid response.
> 
> If the "supports credentials" flag is set to false, the request will be 
> made without cookies, and the server may respond with either 
> "Access-Control-Allow-Origin:*" or "Access-Control-Allow-Origin: 
> ".
> 
> I propose that the latter mode is used as it will make servers easier to 
> configure as they can just add a static header to all their responses.

On Tue, 17 May 2011, Glenn Maynard wrote:
> 
> This could be specified, eg.  without credentials and  cors="credentials"> with.  I don't know if there are use cases to 
> justify it.

On Tue, 17 May 2011, Kenneth Russell wrote:
> 
> In general I think we need to enable as close behavior to the normal 
> image fetching code path as possible. For example, a mashup might 
> require you to be logged in to a site in order to display thumbnails of 
> movie trailers. If normal image fetches send cookies, then it has to be 
> possible to send them when doing a CORS request. I like the idea of  cors> vs. .

I've added a content attribute to , , and  that makes 
the image or media resource be fetched with CORS And have the origin of 
the page if CORS succeeded.

The attribute is "cross-origin" and it has two allowed values, 
"use-credentials" and "anonymous". The latter is the default, so you can 
just say .

This is only a first draft, I'm not sure it's perfect. In particular, 
right now cross-origin media is not allowed at all without this attribute 
(this is not a new change, but I'm not sure it's what implementations do). 
Also, right now as specced if you give a local URL that redirects to a 
remote URL, I don't have CORS kick in, even if you specified cross-origin. 
(This is mostly an editorial thing, I'm going to wait for Anne to get back 
and then see if he can help me out with some editorial changes to CORS to 
make it easier to make that work generally.)

Implementation and author experience feedback would be very welcome on 
this.


On Tue, 17 May 2011, Kenneth Russell wrote:
> 
> Perhaps an API could also be added to find out whether the server 
> granted CORS access to the resulting media, though this is less 
> important. (Note that the canvas element does not have an explicit API 
> for querying the origin-clean flag.)

I haven't exposed this. You can work around it by trying to use the image 
in a canvas, then rereading the canvas, and seeing if you get a security 
error. If there are compelling use cases for that I'd be happy to add an 
API to handle this feature to the DOM though.

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

Re: [whatwg] Interaction of and CSS white-space

[Boris Zbarsky]

On 5/17/11 6:48 PM, Aryeh Gregor wrote:

On Tue, May 17, 2011 at 12:37 AM, Robert O'Callahan
  wrote:

Amazingly, our line breaking rationale is actually quite well documented!
https://wiki.mozilla.org/Gecko:Line_Breaking
Some comments on UAX#14:
http://www.cs.tut.fi/~jkorpela/unicode/linebr.html


Interesting.  I might be misremembering what I read in UAX#14 -- I
didn't look too closely, and it was a while ago.  In any event, my
main point was that I don't think this is just a QoI issue, it should
really be specced.


Unless you think we can come up with the perfect linebreak 
identification and prioritization algorithm (_especially_ 
prioritization), it seems like 100% a QoI issue.


I'm fine with having informative text about this.  I'm fine with having 
some normative requirements.


But I'm not fine, for example, with a spec that either requires or 
forbids the use of the Knuth and Plass algorithm, say.


-Boris

Re: [whatwg] Interaction of and CSS white-space

[Aryeh Gregor]

On Mon, May 16, 2011 at 9:02 PM, Tab Atkins Jr.  wrote:
> I suspect you're thinking of the site I filed a bug against Webkit
> for: 

Yep.

On Tue, May 17, 2011 at 12:37 AM, Robert O'Callahan
 wrote:
> Amazingly, our line breaking rationale is actually quite well documented!
> https://wiki.mozilla.org/Gecko:Line_Breaking
> Some comments on UAX#14:
> http://www.cs.tut.fi/~jkorpela/unicode/linebr.html

Interesting.  I might be misremembering what I read in UAX#14 -- I
didn't look too closely, and it was a while ago.  In any event, my
main point was that I don't think this is just a QoI issue, it should
really be specced.

Re: [whatwg] CORS requests for image and video elements

[Kenneth Russell]

On Tue, May 17, 2011 at 2:52 PM, Glenn Maynard  wrote:
> On Tue, May 17, 2011 at 5:40 PM, Jonas Sicking  wrote:
>>
>> If the "supports credentials" flag is set to false, the request will
>> be made without cookies, and the server may respond with either
>> "Access-Control-Allow-Origin:*" or "Access-Control-Allow-Origin:
>> ".
>>
>> I propose that the latter mode is used as it will make servers easier
>> to configure as they can just add a static header to all their
>> responses.
>
> This could be specified, eg.  without credentials and  cors="credentials"> with.  I don't know if there are use cases to justify
> it.

In general I think we need to enable as close behavior to the normal
image fetching code path as possible. For example, a mashup might
require you to be logged in to a site in order to display thumbnails
of movie trailers. If normal image fetches send cookies, then it has
to be possible to send them when doing a CORS request. I like the idea
of  vs. .

-Ken

Re: [whatwg] CORS requests for image and video elements

[Glenn Maynard]

On Tue, May 17, 2011 at 5:40 PM, Jonas Sicking  wrote:

> If the "supports credentials" flag is set to false, the request will
> be made without cookies, and the server may respond with either
> "Access-Control-Allow-Origin:*" or "Access-Control-Allow-Origin:
> ".
>
> I propose that the latter mode is used as it will make servers easier
> to configure as they can just add a static header to all their
> responses.
>

This could be specified, eg.  without credentials and  with.  I don't know if there are use cases to justify
it.

-- 
Glenn Maynard

Re: [whatwg] CORS requests for image and video elements

[Jonas Sicking]

On Tue, May 17, 2011 at 2:25 PM, Kenneth Russell  wrote:
> Last week, a proof of concept of a previously theoretical timing
> attack against WebGL was published which allows theft of cross-domain
> images' content.
>
> To address this vulnerability it appears to be necessary to ban the
> use of cross-domain images and videos in WebGL. Unfortunately, doing
> so will prevent entire classes of applications from being written, and
> break a not insignificant percentage of current applications.
>
> We would like to use CORS to solve this problem; if the server grants
> access to the image or video, WebGL can use it. Initial discussions
> with image hosting services have been positive, and it seems that CORS
> support could be enabled fairly quickly. Many such services already
> support other access control mechanisms such as Flash's
> crossdomain.xml. Unfortunately, experimentation indicates that it is
> not possible to simply send CORS' Origin header with every HTTP GET
> request for images; some servers do not behave properly when this is
> done.
>
> We would like to propose adding a new Boolean property, useCORS, to
> HTMLImageElement and HTMLMediaElement, defaulting to false. If set to
> true, then HTTP requests sent for these elements will set the Origin
> header from the page's URL. If the Access-Control-Allow-Origin header
> in the response grants access, then the content's origin will be
> treated as the same as the page's.
>
> Perhaps an API could also be added to find out whether the server
> granted CORS access to the resulting media, though this is less
> important. (Note that the canvas element does not have an explicit API
> for querying the origin-clean flag.)
>
> Thoughts on this proposal? We would like to decide on a path quickly
> so that we can update both specs and implementations.

I like the general idea, though i'm not too excited about the name
"useCORS". But lets leave that bikeshedding for a more boring day :)

There is however one more decision that needs to be done. Does setting
"useCORS" make the CORS implementation execute with the "supports
credentials" flag set to true or false?

When set to true, the request to the server will contain the normal
cookies which the user has set for that domain. However, the response
from the server will have to contain "Access-Control-Allow-Origin:
". In particular "Access-Control-Allow-Origin:*" will not be
treated as a valid response.

If the "supports credentials" flag is set to false, the request will
be made without cookies, and the server may respond with either
"Access-Control-Allow-Origin:*" or "Access-Control-Allow-Origin:
".

I propose that the latter mode is used as it will make servers easier
to configure as they can just add a static header to all their
responses.

/ Jonas

[whatwg] CORS requests for image and video elements

[Kenneth Russell]

Last week, a proof of concept of a previously theoretical timing
attack against WebGL was published which allows theft of cross-domain
images' content.

To address this vulnerability it appears to be necessary to ban the
use of cross-domain images and videos in WebGL. Unfortunately, doing
so will prevent entire classes of applications from being written, and
break a not insignificant percentage of current applications.

We would like to use CORS to solve this problem; if the server grants
access to the image or video, WebGL can use it. Initial discussions
with image hosting services have been positive, and it seems that CORS
support could be enabled fairly quickly. Many such services already
support other access control mechanisms such as Flash's
crossdomain.xml. Unfortunately, experimentation indicates that it is
not possible to simply send CORS' Origin header with every HTTP GET
request for images; some servers do not behave properly when this is
done.

We would like to propose adding a new Boolean property, useCORS, to
HTMLImageElement and HTMLMediaElement, defaulting to false. If set to
true, then HTTP requests sent for these elements will set the Origin
header from the page's URL. If the Access-Control-Allow-Origin header
in the response grants access, then the content's origin will be
treated as the same as the page's.

Perhaps an API could also be added to find out whether the server
granted CORS access to the resulting media, though this is less
important. (Note that the canvas element does not have an explicit API
for querying the origin-clean flag.)

Thoughts on this proposal? We would like to decide on a path quickly
so that we can update both specs and implementations.

Thanks,

-Ken

Re: [whatwg] Pressing Enter in contenteditable: or or ?

[Ryosuke Niwa]

On Tue, May 17, 2011 at 12:50 PM, Aryeh Gregor wrote:
>
>  On Tue, May 17, 2011 at 3:19 AM, Ryosuke Niwa  wrote:
> > I completely disagree. As a user, I want semantics when I write my blog
> > entry on WordPress so that I can tweak presentation afterwards.  e.g. I
> have
> > frequently used em {font-style: normal; font-weight:bold;} strong
> > {text-decoration:underline; font-weight: normal;} in the past.
>
> Then the commands will completely break no matter what you do, because
> they're tied to the CSS, not the HTML element.  For instance, in this
> test case:
>

No, I apply those CSS styles only on readonly published pages so my editor
isn't affected by those rules.

- Ryosuke

Re: [whatwg] Pressing Enter in contenteditable: or or ?

[Aryeh Gregor]

On Tue, May 17, 2011 at 3:04 AM, Markus Ernst  wrote:
> If the behavior is settable, it might even be a good idea to leave the
> choice of the standard behavior to the UAs. Authors who have a reason to
> care can set their preferred behavior, while other authors might prefer to
> leave it as it was, so there is no change for their existing users.

We can't leave the default behavior undefined for something like this.
 It affects interoperability, and there's no reason browsers should
differ ("we can't make up our mind" is not a good enough reason).

On Tue, May 17, 2011 at 3:19 AM, Ryosuke Niwa  wrote:
> I completely disagree. As a user, I want semantics when I write my blog
> entry on WordPress so that I can tweak presentation afterwards.  e.g. I have
> frequently used em {font-style: normal; font-weight:bold;} strong
> {text-decoration:underline; font-weight: normal;} in the past.

Then the commands will completely break no matter what you do, because
they're tied to the CSS, not the HTML element.  For instance, in this
test case:



em { font-style: normal; font-weight: bold }

Hello

var text = document.querySelector("em").firstChild;
getSelection().collapse(text, 1);
getSelection().extend(text, 4);
document.execCommand("bold");


Chrome 12 dev produces Hello.  If you change the
command from "bold" to "italic", it becomes Hello.
These commands are specifically presentational, tied to CSS rather
than HTML, which is reflected both in their name and function.

There are other commands that are semantic, like heading or
insertOrderedList.  But you definitely cannot sanely use  for bold
with this API.  We'd have to add new commands like "emphasize" to
allow that.

> And when I press enter, I want a paragraph separator NOT a line break.

WebKit outputs , but a paragraph separator should be .

On Tue, May 17, 2011 at 3:26 AM, Markus Ernst  wrote:
> Imagine a content of the contenteditable element like:
>
> Foo
> Bar
>
> The user puts the caret to the end of the first line and clicks Enter. With
> a strict / behavior, this is a well-defined action, adding a new
> paragraph resp. inserting a newline. But if you go with s, this will
> possibly mess up the code in a way that is hard to fix (though it is valid
> and serializable HTML).

Yeah,  has the advantage over  that  is used for lots of
things, and it might be nice to distinguish.  I don't know.  Since
there are no really good arguments I can see in any direction, I guess
it makes the most sense to standardize the plurality position, namely
some variant of IE/Opera ( on Enter and  on Shift-Enter), with
switches to allow authors to change from the default.  I added it as
an issue to the spec, and will probably look at it reasonably soon:

http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=70be7878

Re: [whatwg] ...

[Robert O'Callahan]

On Wed, May 18, 2011 at 7:09 AM, Robert O'Callahan wrote:

> Sure! For certain kinds of events ("load", the video events, maybe more),
> delay the firing of such events until, say, after DOMContentLoaded has
> fired. If you're careful you might be able to make this a strict subset of
> the behaviors currently allowed by the spec ... i.e. you're pretending that
> your frame, image and video loads simply didn't complete until after
> DOMContentLoaded fired in the outer page. That would mean it's compatible
> with properly-written legacy content ... if there is any.
>
> Of course I have no idea whether that approach is actually feasible :-). It
> obviously isn't compatible with what browsers currently do, so authors
> wouldn't want to rely on it for a long time if ever.
>

However, given authors are already relying on this behavior, if it's
feasible it would probably improve app reliability and interop.

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]

Re: [whatwg] ...

[Robert O'Callahan]

On Tue, May 17, 2011 at 9:09 PM, Philip Jägenstedt wrote:

> To target this specific pattern, one hypothetical solution would be to
> special-case the first script that attaches event handlers to a 
> element. After it has run, all events that were already fired before the
> script are fired again. However, this seems awfully messy if the script also
> observes readyState or networkState. It might also interfere with browsers
> that use scripts behind the scenes to implement the native controls.
>
> Although a kludge, another solution might be to block events from being
> fired until x more bytes of the document have been parsed or it has finished
> loading.
>
> Any other bad ideas?


Sure! For certain kinds of events ("load", the video events, maybe more),
delay the firing of such events until, say, after DOMContentLoaded has
fired. If you're careful you might be able to make this a strict subset of
the behaviors currently allowed by the spec ... i.e. you're pretending that
your frame, image and video loads simply didn't complete until after
DOMContentLoaded fired in the outer page. That would mean it's compatible
with properly-written legacy content ... if there is any.

Of course I have no idea whether that approach is actually feasible :-). It
obviously isn't compatible with what browsers currently do, so authors
wouldn't want to rely on it for a long time if ever.

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]

Re: [whatwg] Proposal: content-style attribute for contenteditable elements

[Boris Zbarsky]

On 5/17/11 2:40 PM, Tab Atkins Jr. wrote:

Doesn't really matter to me; either seems sensical.  :root has the
benefit of existing.  ^_^


:scope has the benefit of making more sense (and happens to exist in my 
tree, is used in the proposed selectors API, etc).


-Boris

Re: [whatwg] Proposal: content-style attribute for contenteditable elements

[Tab Atkins Jr.]

On Tue, May 17, 2011 at 11:05 AM, Boris Zbarsky  wrote:
> On 5/17/11 11:23 AM, Tab Atkins Jr. wrote:
>> On Tue, May 17, 2011 at 1:09 AM, Markus Ernst  wrote:
>>> Special cases:
>>> - If the linked CSS document contains declarations for the body element,
>>> they are applied to the contenteditable element itself. (This could be
>>> necessary in case of light text on dark backgrounds, where you want to
>>> apply
>>> the background to the contenteditable area.)
>>
>> It would be cleaner to simply say that the contenteditable element
>> matches the :root pseudoclass in the linked sheet.
>
> :root, or :scope?

Doesn't really matter to me; either seems sensical.  :root has the
benefit of existing.  ^_^

~TJ

Re: [whatwg] Proposal: content-style attribute for contenteditable elements

[Boris Zbarsky]

On 5/17/11 11:23 AM, Tab Atkins Jr. wrote:

On Tue, May 17, 2011 at 1:09 AM, Markus Ernst  wrote:

Special cases:
- If the linked CSS document contains declarations for the body element,
they are applied to the contenteditable element itself. (This could be
necessary in case of light text on dark backgrounds, where you want to apply
the background to the contenteditable area.)


It would be cleaner to simply say that the contenteditable element
matches the :root pseudoclass in the linked sheet.


:root, or :scope?

-Boris

Re: [whatwg] ...

[Glenn Maynard]

On Tue, May 17, 2011 at 5:09 AM, Philip Jägenstedt wrote:

> To target this specific pattern, one hypothetical solution would be to
> special-case the first script that attaches event handlers to a 
> element. After it has run, all events that were already fired before the
> script are fired again. However, this seems awfully messy if the script also
> observes readyState or networkState. It might also interfere with browsers
> that use scripts behind the scenes to implement the native controls.
>
> Although a kludge, another solution might be to block events from being
> fired until x more bytes of the document have been parsed


Masking the bug harder seems risky.  The problem would still exist, it would
just be a bit more obscure and even less understood.

or it has finished loading.
>

I imagine anything done here should be done for all load-related events,
like .  It's probably not good to effectively disable
asynchronous load events for images.

These events could be split into two parts: one which is deferred until the
document is finished loading ("load", "canplay") and less obviously-named
ones which are fired normally ("asyncload", "asynccanplay"), which people
are unlikely to use without at least looking at documentation to know they
exist.  That would give a "safe", less-racy event by default, and give a
somewhat less obviously-named event for people who know what they're doing
and really don't want these events deferred.

That would regress performance for existing pages, though.

-- 
Glenn Maynard

Re: [whatwg] Proposal: content-style attribute for contenteditable elements

[Tab Atkins Jr.]

On Tue, May 17, 2011 at 1:09 AM, Markus Ernst  wrote:
> Special cases:
> - If the linked CSS document contains declarations for the body element,
> they are applied to the contenteditable element itself. (This could be
> necessary in case of light text on dark backgrounds, where you want to apply
> the background to the contenteditable area.)

It would be cleaner to simply say that the contenteditable element
matches the :root pseudoclass in the linked sheet.


> Rationale:
> - In today's iframe-based online rich text editors, it is common to apply
> the styles of the target page of the edited text to the source document of
> the iframe. This is not possible in a .
> - For many use cases, such as forum and blog entries, or non-fullpage
> oriented web content management systems,  is easier to
> implement than iframe-based editors. The only downside is the WYSIWYG issue.

Why not just use an  with a contenteditable inside the linked
page?  This also gives you the ability to link in arbitrary CSS and be
shielded from the outside page's CSS, and as long as the linked page
is same-origin, you can still fiddle with it from script in the outer
page.

~TJ

Re: [whatwg] ...

[Philip Jägenstedt]

On Tue, 17 May 2011 10:47:02 +0200, Remy Sharp  wrote:


On 17 May 2011, at 09:04, Philip Jägenstedt wrote:


Or do you mean a spec bug?


I meant a spec bug :)


http://www.w3.org/Bugs/Public/show_bug.cgi?id=12664

Still, I don't think just advocacy is any kind of solution. Given that you  
(the co-author of an HTML5 book) make certain assumptions about the  
outcome of this race condition, it's safe to assume that hoards of web  
developers will do the same.


To target this specific pattern, one hypothetical solution would be to  
special-case the first script that attaches event handlers to a   
element. After it has run, all events that were already fired before the  
script are fired again. However, this seems awfully messy if the script  
also observes readyState or networkState. It might also interfere with  
browsers that use scripts behind the scenes to implement the native  
controls.


Although a kludge, another solution might be to block events from being  
fired until x more bytes of the document have been parsed or it has  
finished loading.


Any other bad ideas?

--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] ...

[Remy Sharp]

On 17 May 2011, at 09:04, Philip Jägenstedt wrote:

> Or do you mean a spec bug?

I meant a spec bug :)

[whatwg] Proposal: content-style attribute for contenteditable elements

[Markus Ernst]

Hello

While discussing about contenteditable elements, the WYSIWYG aspect was 
mentioned. For real WYSIWYG in a text editor of a CMS, Blog, Forum or 
whatever, it would be necessary for the contents of the contenteditable 
element to:

- Disable the styles of the surrounding page
- Enable the styles of the target page

This could be solved with a @content-style attribute which takes a URL 
pointing to an external stylesheet document. If the attribute is 
present, all styles of the surrounding page are ignored, and the styles 
of the linked CSS document are applied to the content of the element.


Special cases:
- If the linked CSS document contains declarations for the body element, 
they are applied to the contenteditable element itself. (This could be 
necessary in case of light text on dark backgrounds, where you want to 
apply the background to the contenteditable area.)
- If there are conflicts between body element styles in the linked 
stylesheet and the styles of the contenteditable element in the 
surrounding page, the latter win. (This is necessary to keep the 
dimensions of the input UI, if an author links the whole CSS of the 
target page.)


Rationale:
- In today's iframe-based online rich text editors, it is common to 
apply the styles of the target page of the edited text to the source 
document of the iframe. This is not possible in a .
- For many use cases, such as forum and blog entries, or non-fullpage 
oriented web content management systems,  is easier 
to implement than iframe-based editors. The only downside is the WYSIWYG 
issue.


I'd be happy to read some comments on this idea!

Re: [whatwg] ...

[Philip Jägenstedt]

On Mon, 16 May 2011 17:59:43 +0200, Remy Sharp  wrote:


Hi all,

Since this is *my* code that we're talking specifically about, I'd like  
to repeat Glenn's point that this is not sloppy code (the cheeky shit),  
and that the /everyman/ developer is going to think that attaching an  
event is perfectly legal and will expect it to work.


Now you're right, whoever pointed out the 7am alarm example, if you  
attach the event too late, then you'll miss the boat.  However, it's a  
chicken an egg situation.  You don't have the DOM so you can't attach  
the event handler, and if you do have the DOM, the damn event has fired  
already.


What's the fix?  Well, the work arounds are certainly viable, again from  
an everyman developer point of view:


1) Attach higher up, on the window object and listen for the  
canplay/loadedmetadata/etc and check the event.target

2) Attach an inline event handler (not nice, but will do)

The fix?  Since ultimately we have exactly the same potential "bug" with  
image load events, is to update the specification and make it clear:  
that depending on the speed of the connection and decoding, the  
following "xyz" events can fire **before** your script runs.  Therefore,  
here's a couple of work arounds - or just be aware.


If we fail to come up with a better solution, then warning about the issue  
in big, bold, red letters is the least the spec should do, yes.


Any objections?  At the same time, does someone want to raise this as a  
bug?


I already did: https://github.com/remy/html5demos/issues/12

Or do you mean a spec bug?

--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] Pressing Enter in contenteditable: or or ?

[Markus Ernst]

Am 13.05.2011 12:00 schrieb Michael A. Puls II:

On Thu, 12 May 2011 16:28:47 -0400, Aryeh Gregor
 wrote:

Another problem with  is that it's very easy to create
unserializable DOMs with it. I've seen cases where at least some
browsers will put things inside  that will break out of the ,
and I've done it myself by mistake too.


I think the browser/editor just shouldn't allow that in this case. (Not
saying that it's easy to enforce it though.)


As an author or CMS implementor I'd be happy to see UAs solve this for 
me, creating a valid sequence of paragraphs.


OTOH, if you use s in order to keep the output serializable, this 
might lead to kind of messy code.


Imagine a content of the contenteditable element like:

Foo
Bar

The user puts the caret to the end of the first line and clicks Enter. 
With a strict / behavior, this is a well-defined action, adding a 
new paragraph resp. inserting a newline. But if you go with s, this 
will possibly mess up the code in a way that is hard to fix (though it 
is valid and serializable HTML).

Re: [whatwg] Pressing Enter in contenteditable: or or ?

[Ryosuke Niwa]

On Mon, May 16, 2011 at 12:20 PM, Aryeh Gregor wrote:
>
>  > This is very presentational thinking.
>
> Correct.  This API was designed and is used presentationally, not
> semantically.  Both authors and users want presentational formatting
> here.  That's why it's called "What You *See* Is What You Get".
>

I completely disagree. As a user, I want semantics when I write my blog
entry on WordPress so that I can tweak presentation afterwards.  e.g. I have
frequently used em {font-style: normal; font-weight:bold;} strong
{text-decoration:underline; font-weight: normal;} in the past.

And when I press enter, I want a paragraph separator NOT a line break.

- Ryosuke

Re: [whatwg] Pressing Enter in contenteditable: or or ?

[Markus Ernst]

Am 16.05.2011 21:20 schrieb Aryeh Gregor:

On Mon, May 16, 2011 at 9:33 AM, Markus Ernst  wrote:

I have seen content management systems where text editors tweak the enter
key to behave the same also in non-IE UAs (e.g. if you use Contenido with
TinyMCE, Firefox produces the same output as IE when you hit enter).


I mentioned one forum (vBulletin) which used to set margin to 0 on
paragraphs so that IE looked the same as non-IE browsers.  So it's an
argument for giving authors an option, maybe, but it doesn't help us
decide what the default should be.


This is very presentational thinking.


Correct.  This API was designed and is used presentationally, not
semantically.  Both authors and users want presentational formatting
here.  That's why it's called "What You *See* Is What You Get".


Right, but this does not answer the question about the best standard 
behavior for the enter key. For real WYSIYWYG, it would be necessary to 
introduce a mechanism to apply some CSS separate from the surrounding 
page to the contenteditable element, so CMS or forum authors can provide 
the styles of the output page in the input element. (This is actually 
the case in iframe-based RTEs such as Kevin Roth's Cross-Browser RTE or 
TinyMCE.)


I assume there are use cases for both generating s and s. The 
IE/Opera approach has the advantage of allowing both, which is perfect 
for text and basic HTML editing. From a WYSIWYG POV it might be best to 
offer both options, so authors are not encouraged to add server-side 
processing to change the output, which would break WYSIWYG.


If the behavior is settable, it might even be a good idea to leave the 
choice of the standard behavior to the UAs. Authors who have a reason to 
care can set their preferred behavior, while other authors might prefer 
to leave it as it was, so there is no change for their existing users.