Re: [whatwg] Proposed simplification to Microdata

[Tab Atkins Jr.]

On Thu, May 26, 2011 at 12:02 PM, Guha  wrote:
> We are trying to simplify statement of a fairly common thing that crops up
> with microdata
>
> E.g.,
>
> Consider the block:
> 1) http://schema.org/Book”>
>      The Catcher in the Rye -
>     by J.D. Salinger
>   
>
> Now, the site wants to use the wikipedia (or freebase) entry for Salinger,
> just to be clear and wants the value of the  hasAuthor property to be an
> item with that ID.
> I believe the following says that:
>
> 2) http://schema.org/Book”>
>      The Catcher in the Rye -
>   by http://en.wikipedia.org/wiki/J._D._Salinger";
> itemprop=”hasAuthor”>J.D.
> Salinger
>   
>
> Often, the site does not want to link out to the wikipedia (or other
> canonical url) page, but only specify
> it in the microdata. This can be done by:
>
> 3) http://schema.org/Book”>
>     The Catcher in the Rye -
>   by  itemid="http://en.wikipedia.org/wiki/J._D._Salinger";
> itemprop=”hasAuthor”>J.D.
> Salinger
>  

No, that's invalid:
"The itemid attribute must not be specified on elements that do not
have both an itemscope attribute and an itemtype attribute specified,
and must not be specified on elements with an itemscope attribute
whose itemtype attribute specifies a vocabulary that does not support
global identifiers for items, as defined by that vocabulary's
specification."

The correct way to solve this case is with markup like this:

http://scheme.org/Book";>
  The Catcher in the Rye -
  by J.D. Salinger
  http://en.wikipedia.org/wiki/J._D._Salinger";>


 and  are defined to be allowed in the  specifically
to carry non-visible Microdata information.

~TJ

Re: [whatwg] Request for feedback: supported elements for formatBlock

[Ehsan Akhgari]

On 11-05-26 12:27 PM, Aryeh Gregor wrote:

I don't think any of this justifies adding blockquote, which is not
supported by all browsers and whose *usual* use is to contain multiple
blocks of content.


It seems to me that "blockquote" here interferes in functionality with 
the indent and outdent commands.  Given that, I'm fine with it being 
dropped from formatBlock in the spec.



As for Chrome or Opera, their way of doing things might make sense in
some cases for blockquote, but usually you want the way indent behaves
instead.  If I select two paragraphs and want to put a blockquote
around them, normally I want a two-paragraph blockquote, not a
two-line blockquote or two blockquotes.  It doesn't make any sense at
all for things like article -- you want
foobar, not
foobar  and certainly not
foobar.


I disagree.  It depends on context.


In what context would you want to convert
foobarbaz, say, into
foobarbaz  instead of
foobarbaz?  If you really
wanted to do this, we should have a command to convert/  into
, and a separate command to wrap or unwrap in tags like
along the lines of indent/outdent.  What are the use-cases for wanting
to wrap in  anyway?  What are the use-cases for wanting to
wrap in  where indent/outdent don't work?


I think dropping block elements in this way is not what the user and the 
author would expect most of the time.


Ehsan

Re: [whatwg] Request for feedback: supported elements for formatBlock

[Ehsan Akhgari]

On 11-05-26 4:40 PM, Aryeh Gregor wrote:

I'm still skeptical that no web content depends on blockquote being
supported by FormatBlock on WebKit.  You might argue that they'll have to
modify anyway due to IE not supporting it but most of editors do feature /
browser detection and heavily rely on their current behavior.


I just looked a bit more closely, and it turns out no one except
WebKit treats blockquote like other elements.  Given
foo  with "foo" selected, if you run
execCommand("formatBlock", false, ""), Chrome 13 dev produces
"foo".  IE9, Firefox 5.0a2, and Opera 11.10 produce
"foo", which is what my current spec
says too.  So on that score, clearly WebKit's behavior is going to be
less web-compatible than the current spec.  On the other hand, Gecko's
and Opera's wrapping behavior means the command createss
it can't remove, which doesn't seem useful at all.  IE's behavior
makes the most sense, and is as likely to be web-compatible as any of
the other three behaviors.


What is IE's behavior in this case?


And WebKit is
also a part of Mac OS X framework and native applications that use WebKit as
a part of their applications have no incentive to support Trident, Gecko, or
Opera behaviors.


I'm aiming to write something that works well for the web.  If you
have lots of non-web engine-specific content, maybe you'll eventually
need to have multiple modes, the way IE handles IE-only intranet
content.


As Boris said, and Ryosuke agreed, non-web consumers of any rendering 
engine should not affect what we specify for the web.  WebKit is free to 
have its non-web interface for other consumers if it needs to (as Gecko 
does today).



Okay, I'm fine with that.  But I'm still not convinced that WebKit should
drop the support for other elements because there is virtually no benefit in
dropping the support other than the fact we'll conform to the spec.
In general, I'm not convinced that all browsers should support the exact set
of elements for FormatBlock.  Having the set of elements supported by all
browsers seems to suffice.


It doesn't, as the example given above shows.  Supporting
blockquote/article/etc. the way WebKit does changes the behavior of
execCommand("formatBlock", false, "") also, in common cases.  Try
getting out an execCommand()-based WYSIWYG editor, type some text,
indent it, and then make it a header or pre or something.  In WebKit,
and only WebKit, this outdents the text.  That's very unexpected
behavior for the user.


I agree.  I think WebKit's behavior in this case is not ideal.

Ehsan

Re: [whatwg] "Content-Disposition" property for tags

[Michal Zalewski]

> Browsers should just use the same behaviour when encountering the function
> in a HTML attribute.

Keep in mind that the mechanism *is* extremely imperfect. It only
works for MIME types and extensions recognized by the browser (which
is a small list). There's a large disconnect between this set, the set
handled by the OS, and the actual logic used to control content
disposition later on (much more messy on Linux than on Windows,
interestingly).

Unless it becomes common for file systems to support MIME type
metadata for every file, and for all client applications to honor it,
I really think that giving the markup such control over content
disposition does more harm than good.

/mz

Re: [whatwg] Proposal for separating script downloads and execution

[James Robinson]

On Thu, May 26, 2011 at 3:49 PM, Aryeh Gregor wrote:

> On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas 
> wrote:
> > I'm a little surprised that this conversation has swooped back around to
> performance and whether or not there's a valid use case here. In addition to
> standalone solutions like Steve's ControlJS and Kyle's LABjs, the Mozilla
> and Chrome teams were also trying to come up with solutions to enable
> preloading of JavaScript. What I was hoping for was a consolidation of the
> efforts rather than a discussion as to whether or not such efforts should
> continue.
>
> The question isn't whether or not such efforts should continue, it's
> whether any features need to be added to web standards to help the
> efforts continue.  This is a web standards discussion list, after all,
> not a list about user JavaScript library development, or browser
> implementation.  If it turns out that the libraries can be developed
> just fine with existing standard features, like perhaps if browsers
> improve 

Re: [whatwg] Proposal for separating script downloads and execution

[Aryeh Gregor]

On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas  wrote:
> I'm a little surprised that this conversation has swooped back around to 
> performance and whether or not there's a valid use case here. In addition to 
> standalone solutions like Steve's ControlJS and Kyle's LABjs, the Mozilla and 
> Chrome teams were also trying to come up with solutions to enable preloading 
> of JavaScript. What I was hoping for was a consolidation of the efforts 
> rather than a discussion as to whether or not such efforts should continue.

The question isn't whether or not such efforts should continue, it's
whether any features need to be added to web standards to help the
efforts continue.  This is a web standards discussion list, after all,
not a list about user JavaScript library development, or browser
implementation.  If it turns out that the libraries can be developed
just fine with existing standard features, like perhaps if browsers
improve 

Re: [whatwg] "Content-Disposition" property for tags

[Dennis Joachimsthaler]

Am 26.05.2011, 22:58 Uhr, schrieb Julian Reschke :


On 2011-05-26 22:54, Dennis Joachimsthaler wrote:

Am 26.05.2011, 22:53 Uhr, schrieb Boris Zbarsky :


Probably no one, to a first approximation, but we were specifically
talking about non-Windows systems. On Windows, as I said, Gecko forces
extensions to match content types, to avoid this sort of issue in
general.


Yep, yep... If browsers implement the filename (+ extension) name  
changing

we should make it a MUST to implement security...
...


Like  
?


Best regards, Julian


Ah, that sort of security is a SHOULD here, already.

We should just copy this over, it looks good.

Browsers should just use the same behaviour when encountering the function  
in

a HTML attribute.

I forsee a great future :-)


- Dennis Joachimsthaler

Re: [whatwg] "Content-Disposition" property for tags

[Julian Reschke]

On 2011-05-26 22:54, Dennis Joachimsthaler wrote:

Am 26.05.2011, 22:53 Uhr, schrieb Boris Zbarsky :


Probably no one, to a first approximation, but we were specifically
talking about non-Windows systems. On Windows, as I said, Gecko forces
extensions to match content types, to avoid this sort of issue in
general.


Yep, yep... If browsers implement the filename (+ extension) name changing
we should make it a MUST to implement security...
...


Like 
?


Best regards, Julian

Re: [whatwg] "Content-Disposition" property for tags

[Dennis Joachimsthaler]

Am 26.05.2011, 22:53 Uhr, schrieb Boris Zbarsky :

Probably no one, to a first approximation, but we were specifically  
talking about non-Windows systems.  On Windows, as I said, Gecko forces  
extensions to match content types, to avoid this sort of issue in  
general.


Yep, yep... If browsers implement the filename (+ extension) name changing
we should make it a MUST to implement security...

- Dennis Joachimsthaler

Re: [whatwg] "Content-Disposition" property for tags

[Boris Zbarsky]

On 5/26/11 4:40 PM, Dennis Joachimsthaler wrote:

Though I think it still would happen rarely that a pl file gets downloaded.


The problem is getting the user to save a text file you control as a .pl 
file.



I mean who on the most popular system, Windows, has a Perl interpreter
installed?


Probably no one, to a first approximation, but we were specifically 
talking about non-Windows systems.  On Windows, as I said, Gecko forces 
extensions to match content types, to avoid this sort of issue in general.


-Boris

Re: [whatwg] "Content-Disposition" property for tags

[Dennis Joachimsthaler]

Am 26.05.2011, 22:33 Uhr, schrieb Boris Zbarsky :


On 5/26/11 3:12 PM, Dennis Joachimsthaler wrote:

Oh I see the problem... Is it the bang? #!/bin/perl #!/bin/python
#!/bin/bash
could very well result in the text file being executed in one of those
interpreters,
right?


Yes, but even worse on some systems a .pl file will just handed over to  
the registered handler for those (often a Perl interpreter) if you try  
to "open" it (which is a different operation from "execute" and can be  
done even on files that are not executable; think double-clicking the  
file in a file manager).


-Boris


Ah, I see. So the people using the GUI are in the gutter? Which are
also the people that are inexperienced and would be prone to such attacks.

Damn.

Though I think it still would happen rarely that a pl file gets downloaded.

I mean who on the most popular system, Windows, has a Perl interpreter  
installed?


- Dennis Joachimsthaler

Re: [whatwg] Request for feedback: supported elements for formatBlock

[Aryeh Gregor]

On Thu, May 26, 2011 at 12:53 PM, Ryosuke Niwa  wrote:
> The problem is with queryCommandValue.  One of the reasons we support so
> many block elements is so that queryCommandValue returns a sensible value.
>  For example, if called queryCommandValue('FormatBlock') inside a
> blockquote, I'd expect to get blockquote back, not an empty string.

I'd expect to get an empty string, if there's no line wrapper.  So if
you had "foobar", querying the value would return nothing, and if
you formatted as , it would become "foobar".
Likewise, if you had "foobar", querying
the value would return nothing and formatting as  would get
"foobar".

> I'm still skeptical that no web content depends on blockquote being
> supported by FormatBlock on WebKit.  You might argue that they'll have to
> modify anyway due to IE not supporting it but most of editors do feature /
> browser detection and heavily rely on their current behavior.

I just looked a bit more closely, and it turns out no one except
WebKit treats blockquote like other elements.  Given
foo with "foo" selected, if you run
execCommand("formatBlock", false, ""), Chrome 13 dev produces
"foo".  IE9, Firefox 5.0a2, and Opera 11.10 produce
"foo", which is what my current spec
says too.  So on that score, clearly WebKit's behavior is going to be
less web-compatible than the current spec.  On the other hand, Gecko's
and Opera's wrapping behavior means the command creates s
it can't remove, which doesn't seem useful at all.  IE's behavior
makes the most sense, and is as likely to be web-compatible as any of
the other three behaviors.

(Opera's behavior actually seems a bit complicated.  It will add
blockquote as a wrapper sometimes and replace a preexisting element
sometimes, but it seems it will never remove an existing blockquote.)

> And WebKit is
> also a part of Mac OS X framework and native applications that use WebKit as
> a part of their applications have no incentive to support Trident, Gecko, or
> Opera behaviors.

I'm aiming to write something that works well for the web.  If you
have lots of non-web engine-specific content, maybe you'll eventually
need to have multiple modes, the way IE handles IE-only intranet
content.

> Okay, I'm fine with that.  But I'm still not convinced that WebKit should
> drop the support for other elements because there is virtually no benefit in
> dropping the support other than the fact we'll conform to the spec.
> In general, I'm not convinced that all browsers should support the exact set
> of elements for FormatBlock.  Having the set of elements supported by all
> browsers seems to suffice.

It doesn't, as the example given above shows.  Supporting
blockquote/article/etc. the way WebKit does changes the behavior of
execCommand("formatBlock", false, "") also, in common cases.  Try
getting out an execCommand()-based WYSIWYG editor, type some text,
indent it, and then make it a header or pre or something.  In WebKit,
and only WebKit, this outdents the text.  That's very unexpected
behavior for the user.

Re: [whatwg] "Content-Disposition" property for tags

[Boris Zbarsky]

On 5/26/11 3:12 PM, Dennis Joachimsthaler wrote:

Oh I see the problem... Is it the bang? #!/bin/perl #!/bin/python
#!/bin/bash
could very well result in the text file being executed in one of those
interpreters,
right?


Yes, but even worse on some systems a .pl file will just handed over to 
the registered handler for those (often a Perl interpreter) if you try 
to "open" it (which is a different operation from "execute" and can be 
done even on files that are not executable; think double-clicking the 
file in a file manager).


-Boris

Re: [whatwg] [html5] Question on the structured cloning algorithm

[Ian Hickson]

On Thu, 26 May 2011, Stewart Brodie wrote:
>
> Ian Hickson  wrote:
> 
> > On Tue, 24 May 2011, Stewart Brodie wrote:
> > >
> > > Do getters need to be called to obtain a value which can be stored
> > > (after being cloned itself) in the result?
> > 
> > I'm not sure I follow the question. Can you elaborate?
> 
> Are getters called during cloning?  i.e. what do I get if I clone this:
> 
> { get a() { return 1 } }
> 
> Do I get { a: 1 } or do I get {}  ?

Assuming "a" is an enumerable property of the object, yes, it would be 
copied, which would involve calling the getter.

This causes some unfortunate side-effects, which will be fixed once I get 
around to fixing this bug:

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

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

Re: [whatwg] "Content-Disposition" property for tags

[Dennis Joachimsthaler]

Am 26.05.2011, 21:08 Uhr, schrieb Boris Zbarsky :


Yes, that's the one saving grace.  "Usually" is key, though.


Usually, damn.

There is little practical difference for the user between running a  
binary and running a perl script, and sneaking in a text file with a .pl  
extension might well make the latter happen...


-Boris


Oh I see the problem... Is it the bang? #!/bin/perl #!/bin/python  
#!/bin/bash
could very well result in the text file being executed in one of those  
interpreters,

right?

Re: [whatwg] "Content-Disposition" property for tags

[Boris Zbarsky]

On 5/26/11 2:16 PM, Dennis Joachimsthaler wrote:

Wouldn't this be no immediate problem on Linux type OSs? There's usually
no execution bit set on files downloaded.


Yes, that's the one saving grace.  "Usually" is key, though.


And practically you can run ALL files as binaries, it looks for the ELF header 
as far as I know.


There is little practical difference for the user between running a 
binary and running a perl script, and sneaking in a text file with a .pl 
extension might well make the latter happen...


-Boris

[whatwg] Proposed simplification to Microdata

[Guha]

We are trying to simplify statement of a fairly common thing that crops up
with microdata

E.g.,

Consider the block:
1) http://schema.org/Book”>
  The Catcher in the Rye -
 by J.D. Salinger
   

Now, the site wants to use the wikipedia (or freebase) entry for Salinger,
just to be clear and wants the value of the  hasAuthor property to be an
item with that ID.
I believe the following says that:

2) http://schema.org/Book”>
  The Catcher in the Rye -
   by http://en.wikipedia.org/wiki/J._D._Salinger";
itemprop=”hasAuthor”>J.D.
Salinger
   

Often, the site does not want to link out to the wikipedia (or other
canonical url) page, but only specify
it in the microdata. This can be done by:

3) http://schema.org/Book”>
 The Catcher in the Rye -
   by http://en.wikipedia.org/wiki/J._D._Salinger";
itemprop=”hasAuthor”>J.D.
Salinger
  

In this case, the page is saying nothing more about the object whose
canonical url is
http://en.wikipedia.org/wiki/J._D._Salinger. The itemscope really serves no
purpose.

We would like to propose that it be made legal to drop the itemscope in this
case.
We realize that it is just one term, but this also makes this case symmetric
with (2),
which helps with explaining/understanding microdata.

guha

Re: [whatwg] "Content-Disposition" property for tags

[Dennis Joachimsthaler]

Hi Boris,

Am 26.05.2011, 20:15 Uhr, schrieb Boris Zbarsky :


On 5/26/11 2:06 PM, Dennis Joachimsthaler wrote:


I believe it forces the extension to match the MIME type; if the type  
text/plain the saved filename will be  
"Important_Security_Update.exe.txt".


Ah, alright. This is good though.

Well, in the Firefox case non-Windows OSes, where the theory is that the  
handling of a file does not depend on the extension but the practice is  
... variable.


Wouldn't this be no immediate problem on Linux type OSs? There's usually
no execution bit set on files downloaded. And practically you can run
ALL files as binaries, it looks for the ELF header as far as I know.


-Boris


- Dennis Joachimsthaler

Re: [whatwg] "Content-Disposition" property for tags

[Boris Zbarsky]

On 5/26/11 2:06 PM, Dennis Joachimsthaler wrote:




At least in the case of Firefox for that particular case on Windows
thefilename will be sanitized...


So what does Firefox do in this case?


I believe it forces the extension to match the MIME type; if the type 
text/plain the saved filename will be "Important_Security_Update.exe.txt".



But yes, there are other situations where things could be more
problematic.


Which are these? Please enlighten me.


Well, in the Firefox case non-Windows OSes, where the theory is that the 
handling of a file does not depend on the extension but the practice is 
... variable.


-Boris

Re: [whatwg] "Content-Disposition" property for tags

[Dennis Joachimsthaler]

Oh hey,

I didn't realize this topic was discussed again one month ago.
I originally even started this ;-).


Note that somewhat counterintuitively, there would be some security
concerns with markup-level content disposition controls (or any JS
equivalent). For example, consider evil.com doing this:




At least in the case of Firefox for that particular case on Windows the 
filename will be sanitized...


So what does Firefox do in this case?
Also I think that maybe the "filename" part is not necessary at all.

The filename is only necessary when you feed the file from a dynamic
page, like directly from the PHP processor. And in this case you can
directly use the contend-disposition HTTP header.

I was talking about cases where there are direct links to files that
WOULD open directly, but we want to suggest the browser to download them
instead. In this case we would have to fiddle around with server
side scripting and suggesting the attachment-flag from a HTTP standpoint
even though there is absolutely no other reason than this single http  
header.


More trouble than it's worth.

So if the filename part of this kind of disposition tag is too insecure, we
can leave it out without destroying my intended reason for such a tag.

Of course there might be reasons to have the filename part anyways, let
me write down an example:

You have files in a folder that are numbered in one continous numbering
scheme. The files are heavily downloaded so server side scripting falls
out of the question because sending files through this is, to say the  
least,

slow, unless you use some special tricks.

Instead of giving the user a link to the file called "A342378437.pdf"
you can use the disposition attribute to

a) Let him directly download it. He doesn't have to go the long way
   around by right clicking this way.

b) Give it a meaningful name that the user will appreciate

This is though the initial idea which sparked this thread. And it has been
expanded upon already.

But yes, there are other situations where things could be more  
problematic.


Which are these? Please enlighten me.

- Dennis Joachimsthaler

Re: [whatwg] Request for feedback: supported elements for formatBlock

[Ryosuke Niwa]

On Thu, May 26, 2011 at 10:40 AM, Boris Zbarsky  wrote:

> On 5/26/11 1:25 PM, Ryosuke Niwa wrote:
>
>> Sure. I'm just saying that it'll be hard for us to drop the support for
>> other elements in practice.  I have no problem with spec not including
>> those elements.
>>
>
> Yes, I understand what you're saying.  What I'm saying is that making your
> web-facing behavior depend on what your non-web consumers want is bad for
> the web, no matter what the spec says.
>

I personally concur with your point.

- Ryosuke

Re: [whatwg] Request for feedback: supported elements for formatBlock

[Boris Zbarsky]

On 5/26/11 1:25 PM, Ryosuke Niwa wrote:

On Thu, May 26, 2011 at 10:13 AM, Boris Zbarsky mailto:bzbar...@mit.edu>> wrote:

On 5/26/11 12:53 PM, Ryosuke Niwa wrote:

And WebKit is also a part of Mac OS X framework and native
applications that use WebKit as
a part of their applications have no incentive to support
Trident, Gecko, or
Opera behaviors.


I think this particular argument should have next to no weight when
deciding on _web_ behaviors.  That applies to all of the embeddable
rendering engines; interactions between them and non-web embedders
should NOT be the web's problem.


Sure. I'm just saying that it'll be hard for us to drop the support for
other elements in practice.  I have no problem with spec not including
those elements.


Yes, I understand what you're saying.  What I'm saying is that making 
your web-facing behavior depend on what your non-web consumers want is 
bad for the web, no matter what the spec says.


-Boris

Re: [whatwg] Proposal for separating script downloads and execution

[Glenn Maynard]

On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas  wrote:
> I'm a little surprised that this conversation has swooped back around to 
> performance and whether or not there's a valid use case here.

Stopping and reevaluating periodically is a good idea, when proposing
added complexity to the platform.

> Moving parts of the JavaScript download/execution process doesn't allow me to 
> control when that script will be executed, which as I mentioned in a previous 
> email, is really the crux of the issue.

The crux of the issue, according to your previous mail, was that
executing the top-level of a script has to take a nontrivial amount of
time, which is why you want to control when it happens.  Based on both
benchmarking and logical examination of what's happening, that doesn't
seem to be the case: executing the top-level of a function, when using
the loader-function paradigm, takes no significant time at all.

Can you reply to my mail, and explain why the loader-function paradigm
doesn't work for you?  Maybe we discussed it before, but I'm having
trouble thinking of any problems with it.

> Sorry for repetition, but we can already preload images and CSS and apply 
> them to the page at an arbitrary point in time. Why wouldn't we want the same 
> thing for JavaScript?

You have effectively the same thing with a loader function; it just
takes marginally more cooperation from the resource itself (wrapping
it inside a function), which I think is fine.

-- 
Glenn Maynard

Re: [whatwg] Request for feedback: supported elements for formatBlock

[Ryosuke Niwa]

On Thu, May 26, 2011 at 10:13 AM, Boris Zbarsky  wrote:

> On 5/26/11 12:53 PM, Ryosuke Niwa wrote:
>
>> And WebKit is also a part of Mac OS X framework and native applications
>> that use WebKit as
>> a part of their applications have no incentive to support Trident, Gecko,
>> or
>> Opera behaviors.
>>
>
> I think this particular argument should have next to no weight when
> deciding on _web_ behaviors.  That applies to all of the embeddable
> rendering engines; interactions between them and non-web embedders should
> NOT be the web's problem.
>

Sure. I'm just saying that it'll be hard for us to drop the support for
other elements in practice.  I have no problem with spec not including those
elements.

- Ryosuke

Re: [whatwg] Request for feedback: supported elements for formatBlock

[Boris Zbarsky]

On 5/26/11 12:53 PM, Ryosuke Niwa wrote:

And WebKit is also a part of Mac OS X framework and native applications that 
use WebKit as
a part of their applications have no incentive to support Trident, Gecko, or
Opera behaviors.


I think this particular argument should have next to no weight when 
deciding on _web_ behaviors.  That applies to all of the embeddable 
rendering engines; interactions between them and non-web embedders 
should NOT be the web's problem.


-Boris

Re: [whatwg] Request for feedback: supported elements for formatBlock

[Ryosuke Niwa]

On Thu, May 26, 2011 at 9:27 AM, Aryeh Gregor wrote:

> On Thu, May 26, 2011 at 1:56 AM, Ryosuke Niwa  wrote:
> > WebKit's FormatBlock basically supports all HTML5 elements that are
> display: block by default.
>
> Well, not really.  It doesn't support body, ol, or listing, for
> instance.  It does support many more than any other browser does, and
> I don't think this is useful.
>

The problem is with queryCommandValue.  One of the reasons we support so
many block elements is so that queryCommandValue returns a sensible value.
 For example, if called queryCommandValue('FormatBlock') inside a
blockquote, I'd expect to get blockquote back, not an empty string.

I don't think any of this justifies adding blockquote, which is not
> supported by all browsers and whose *usual* use is to contain multiple
> blocks of content.
>

I'm still skeptical that no web content depends on blockquote being
supported by FormatBlock on WebKit.  You might argue that they'll have to
modify anyway due to IE not supporting it but most of editors do feature /
browser detection and heavily rely on their current behavior.  And WebKit is
also a part of Mac OS X framework and native applications that use WebKit as
a part of their applications have no incentive to support Trident, Gecko, or
Opera behaviors.

(I had to get the id by inspecting the DOM; I think it varies.)  Gmail
> uses the indent and outdent commands for blockquote.  Which makes
> sense, since everyone supports those, and IE doesn't support
> formatBlock with blockquote.  My proposal is to converge on the
> intersection of what all browsers currently support (plus possibly
> dd/dt, which only Opera doesn't support).
>

Okay, I'm fine with that.  But I'm still not convinced that WebKit should
drop the support for other elements because there is virtually no benefit in
dropping the support other than the fact we'll conform to the spec.

In general, I'm not convinced that all browsers should support the exact set
of elements for FormatBlock.  Having the set of elements supported by all
browsers seems to suffice.

- Ryosuke

Re: [whatwg] Request for feedback: supported elements for formatBlock

[Aryeh Gregor]

On Thu, May 26, 2011 at 1:56 AM, Ryosuke Niwa  wrote:
> WebKit's FormatBlock basically supports all HTML5 elements that are display: 
> block by default.

Well, not really.  It doesn't support body, ol, or listing, for
instance.  It does support many more than any other browser does, and
I don't think this is useful.

>>
>> The issue with all the non-IE browsers is that they support a bunch of
>> things that make sense to nest within one another, and formatBlock
>> doesn't work for nesting.  So for instance, if I do
>> execCommand("formatBlock", false, "blockquote") on
>> foobar, what's the result?  Firefox produces
>> foobar, Chrome produces
>> foobar, and Opera produces
>> foobar.
>
> I think Chrome's and Opera's behaviors make most senes here given that 
> FormatBlock removes the current enclosing block and replace it with the 
> specified block in other situations.

Sure, but given that, does it make sense to support blockquote for
formatBlock at all?

> If you argue that blockquote can be nested, then I'd argue that any block 
> elements except p can be nested in various situations.

Of the elements I mentioned (address, div, h*, p, pre), h*, p, and pre
are only allowed to contain phrasing content -- i.e., not block
elements.  address is allowed to contain flow content, but with
significant restrictions (no headers or sections).  Furthermore, to
the extent people use it correctly at all, it will usually contain
only phrasing content.  All examples given in the spec contain only
phrasing content.  As for div, it shouldn't be on the list, but all
browsers support it, so I'm forced to add support unless browsers are
willing to drop it.

I don't think any of this justifies adding blockquote, which is not
supported by all browsers and whose *usual* use is to contain multiple
blocks of content.

>> As for Chrome or Opera, their way of doing things might make sense in
>> some cases for blockquote, but usually you want the way indent behaves
>> instead.  If I select two paragraphs and want to put a blockquote
>> around them, normally I want a two-paragraph blockquote, not a
>> two-line blockquote or two blockquotes.  It doesn't make any sense at
>> all for things like article -- you want
>> foobar, not
>> foobar and certainly not
>> foobar.
>
> I disagree.  It depends on context.

In what context would you want to convert
foobarbaz, say, into
foobarbaz instead of
foobarbaz?  If you really
wanted to do this, we should have a command to convert / into
, and a separate command to wrap or unwrap in tags like 
along the lines of indent/outdent.  What are the use-cases for wanting
to wrap in  anyway?  What are the use-cases for wanting to
wrap in  where indent/outdent don't work?

> I think we have to support blockquote.  The last time I checked, Gmail used 
> FormatBlock to add blockquote around the quoted context.

I checked using:

javascript:var doc =
document.getElementById("canvas_frame").contentWindow.document.getElementById(":et").contentWindow.document;
var execC = doc.execCommand; doc.execCommand = function() {
console.log(arguments[0] + " " + arguments[1] + " " + arguments[2]);
execC.apply(this, arguments); }; void(0);

(I had to get the id by inspecting the DOM; I think it varies.)  Gmail
uses the indent and outdent commands for blockquote.  Which makes
sense, since everyone supports those, and IE doesn't support
formatBlock with blockquote.  My proposal is to converge on the
intersection of what all browsers currently support (plus possibly
dd/dt, which only Opera doesn't support).

Re: [whatwg] Proposal for separating script downloads and execution

[Boris Zbarsky]

On 5/26/11 11:56 AM, Nicholas Zakas wrote:

Sorry for repetition, but we can already preload images and CSS and apply them 
to the page at an arbitrary point in time. Why wouldn't we want the same thing 
for JavaScript?


I think the question is whether you want _more_ than that for JavaScript.

For images, you can preload them and choose when they're shown, but 
_cannot_ choose when they're decoded.


For CSS, you can preload it and choose when it's applied but _cannot_ 
generally choose when it's parsed.


For JS, you want to be able to preload it and control when it's executed 
(in the sense that the side-effects it causes become visible).  The 
question is whether control is also needed over exactly when 
side-effect-free preprocessing of the script happens.


-Boris

Re: [whatwg] Proposal for separating script downloads and execution

[Nicholas Zakas]

I'm a little surprised that this conversation has swooped back around to 
performance and whether or not there's a valid use case here. In addition to 
standalone solutions like Steve's ControlJS and Kyle's LABjs, the Mozilla and 
Chrome teams were also trying to come up with solutions to enable preloading of 
JavaScript. What I was hoping for was a consolidation of the efforts rather 
than a discussion as to whether or not such efforts should continue. 

Moving parts of the JavaScript download/execution process doesn't allow me to 
control when that script will be executed, which as I mentioned in a previous 
email, is really the crux of the issue.

Sorry for repetition, but we can already preload images and CSS and apply them 
to the page at an arbitrary point in time. Why wouldn't we want the same thing 
for JavaScript?

- Nicholas


-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] 
On Behalf Of Ian Hickson
Sent: Thursday, May 26, 2011 12:43 AM
To: Boris Zbarsky
Cc: whatwg; James Robinson
Subject: Re: [whatwg] Proposal for separating script downloads and execution

On Thu, 26 May 2011, Boris Zbarsky wrote:
> On 5/26/11 1:10 AM, Ian Hickson wrote:
> > It's presumably a whole heck of a lot more complex than brack matching:
> > 
> > alert('fail');
> > function test () {
> >   // ...megabytes of perfectly fine code...
> >   a b;
> > }
> > 
> > ...had better not alert anything.
> 
> And in V8 does not, indeed.
> 
> > What we really need though is perf data, e.g. comparing how browsers
> > handle code such as:
> > 
> > 
> >  var times = [];
> >  times.push(new Date());
> > 
> > 
> >  times.push(new Date());
> >  function test() {
> >// ...megabytes of complicated code...
> >  };
> >  times.push(new Date());
> >  test();
> >  times.push(new Date());
> > 
> > 
> > What are the deltas between all the times in various browsers?
> 
> Cute idea.  You have to disentangle effects like the second script's text not
> being fully downloaded yet when the first script runs, so loading from file://
> or at least from cache is good.  You could probably modify the test to use a
> script-inserted script instead, but I suspect that would not change things
> much.
> 
> In any case, I put up that testcase using 4 copies of the non-minified version
> of JQuery 1.6.1 as the "complicated code" at
> .
> The first load will have that downloading issue, but subsequent loads should
> be ok.  Or save to a local file to avoid the network effects.
> 
> I see numbers in ms like so for the deltas (without error bars, but all are
> plus or minus 4ms or so based on eyeballing):
> 
> Firefox Nightly: 60, 0, 17
> Chrome 12 dev: 43, 0, 160 or 19 (the last number is bimodal; this
>  happens from file:// too, so not
>  network-related).
> WebKit nightly: 30, 0, 30
> Opera 11: 22, 0, 10
> IE9 (on different hardware): 32, 0, 67

This suggests (modulo the bimodal behaviour in Chrome, which I assume is a 
bug of some sort) that Chrome in fact does act in a way that distinguishes 
"parsing" (or "compiling" or whatever we want to call the side-effect free 
preprocessing step) from the side-effect inducing "execution" step, and 
the former can be significantly expensive. This supports the earlier point 
bz was making about how that step could be moved off the main thread and 
thus solve what I described as "problem A" in my earlier e-mail.

(I haven't yet looked at the more recent e-mails that describe other use 
cases; I shall get to that in due course. Sorry for the extended delays 
in getting to feedback this year.)

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

Re: [whatwg] [html5] Question on the structured cloning algorithm

[Stewart Brodie]

Ian Hickson  wrote:

> On Tue, 24 May 2011, Stewart Brodie wrote:
> >
> > Do getters need to be called to obtain a value which can be stored
> > (after being cloned itself) in the result?
> 
> I'm not sure I follow the question. Can you elaborate?

Are getters called during cloning?  i.e. what do I get if I clone this:

{ get a() { return 1 } }

Do I get { a: 1 } or do I get {}  ?


-- 
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited

Re: [whatwg] Proposal for separating script downloads and execution

[Ian Hickson]

On Thu, 26 May 2011, Boris Zbarsky wrote:
> On 5/26/11 1:10 AM, Ian Hickson wrote:
> > It's presumably a whole heck of a lot more complex than brack matching:
> > 
> > alert('fail');
> > function test () {
> >   // ...megabytes of perfectly fine code...
> >   a b;
> > }
> > 
> > ...had better not alert anything.
> 
> And in V8 does not, indeed.
> 
> > What we really need though is perf data, e.g. comparing how browsers
> > handle code such as:
> > 
> > 
> >  var times = [];
> >  times.push(new Date());
> > 
> > 
> >  times.push(new Date());
> >  function test() {
> >// ...megabytes of complicated code...
> >  };
> >  times.push(new Date());
> >  test();
> >  times.push(new Date());
> > 
> > 
> > What are the deltas between all the times in various browsers?
> 
> Cute idea.  You have to disentangle effects like the second script's text not
> being fully downloaded yet when the first script runs, so loading from file://
> or at least from cache is good.  You could probably modify the test to use a
> script-inserted script instead, but I suspect that would not change things
> much.
> 
> In any case, I put up that testcase using 4 copies of the non-minified version
> of JQuery 1.6.1 as the "complicated code" at
> .
> The first load will have that downloading issue, but subsequent loads should
> be ok.  Or save to a local file to avoid the network effects.
> 
> I see numbers in ms like so for the deltas (without error bars, but all are
> plus or minus 4ms or so based on eyeballing):
> 
> Firefox Nightly: 60, 0, 17
> Chrome 12 dev: 43, 0, 160 or 19 (the last number is bimodal; this
>  happens from file:// too, so not
>  network-related).
> WebKit nightly: 30, 0, 30
> Opera 11: 22, 0, 10
> IE9 (on different hardware): 32, 0, 67

This suggests (modulo the bimodal behaviour in Chrome, which I assume is a 
bug of some sort) that Chrome in fact does act in a way that distinguishes 
"parsing" (or "compiling" or whatever we want to call the side-effect free 
preprocessing step) from the side-effect inducing "execution" step, and 
the former can be significantly expensive. This supports the earlier point 
bz was making about how that step could be moved off the main thread and 
thus solve what I described as "problem A" in my earlier e-mail.

(I haven't yet looked at the more recent e-mails that describe other use 
cases; I shall get to that in due course. Sorry for the extended delays 
in getting to feedback this year.)

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

Re: [whatwg] Proposal for separating script downloads and execution

[Boris Zbarsky]

On 5/26/11 3:12 AM, James Robinson wrote:

I think there's a valid use case for downloading a script and not
evaluating it immediately.


I think we all agree on that.


The point I was getting at in IRC was that
there is a lot of confusion about what parsing and executing mean in
modern js engines


Well, for one thing they mean different things in different engines.  ;)


and I didn't see much careful measurement in the thread.


There's some measurement now (though not careful, and with various caveats).

-Boris

Re: [whatwg] Proposal for separating script downloads and execution

[James Robinson]

I think there's a valid use case for downloading a script and not evaluating
it immediately. The point I was getting at in IRC was that there is a lot of
confusion about what parsing and executing mean in modern js engines and I
didn't see much careful measurement in the thread.

- James
On May 25, 2011 10:48 PM, "Boris Zbarsky"  wrote: