Re: [whatwg] Canvas feedback (various threads)

[Charles Pritchard]

On Sun, 3 Oct 2010, Charles Pritchard wrote:

Having worked quite awhile with WebApps APIs, Canvas included, I've
concluded that HTML can be implemented within the web stack.
It's my firm belief that the Web Apps specifications can and should be
proven complete.

If by "complete" you mean "self-hosting", then: why? That seems like a
very arbitrary goal.

If not, what do you mean?
I intended that section 4, "The elements of HTML", with minor 
exceptions, should be

displayable with Canvas, and operable with a minimal canvas+webapps profile.

Exceptions include, but are not limited to: script, iframe, embed, 
object, and for some time, video and audio.


There are minimal instances in the current spec, which prohibit this.

For those instances, there are additional use cases, outside of 
'completion',

mainly having relevance to accessibility (a11y).


I'm concerned that the issue is being avoided because it originated from
a project you disagree with; and has biased your judgment of additional
use cases or possible remedies.

Good lord no. This is merely a prioritisation issue. I'm sure we'll add
lots of metrics over time.

But I'm not requesting a discussion on various aspects of fonts.

I'm pointing to the non-availability of one particular metric, as a 
blocking issue in my ability to keep

a string of text on the same baseline.

The problem is that anytime we add anything to canvas, implementors get so
excited that they drop what they're doing and implement it (in some cases,
overnight!). This takes resources away from other features. If we're to
get the whole platform to improve, we need to make sure that everything
gets a chance to be implemented. This means we can't just be adding stuff
to canvas all the time.
I'm no newbie, I understand and appreciate your oversight on html 5 
implementations,
your flexibility in exploring new standards (like WebSRT), and your 
conscientious approach

to managing a living document.

You're making a slippery slope argument, I don't think it fits:
I'd asked for one property to be added to the specs document; as an 
extension

of the textBaseline attribute already in the document.

It's implementation-time is minimal.

It's part of my approach, to give weight to implementation time and scope.


We need to expose baseline positioning somewhere

Why? What's the use case? Implementing a browser isn't a sane use case,
sorry.

Continuing that discussion is not sane...

Exposing the baseline position of inline data would allow for 
fine-grained positioning

of elements and better control of interactivity with text.

Currently, I can't use fillText with two separate font sizes, and 
underline them.


The textBaseline attribute gets me close, but it's insufficient.


Nobody wants to see another vendor-specific extension; can we try to
form an agreement on this, so we can avoid that?

On the contrary, we _do_ want to see vendor-specific extensions. That's
how we get implementation experience and how the Web improves.

Standardisation is the penultimate stage in a feature's development, after
studying author practices, experimental implementations in vendor-specific
features, and studying use cases, and ahead only of the final convergence
of browser implementations


Your enthusiasm for the "final convergence" is charming.

I made a poor generalization. Most of us do not want to see 
vendor-specific extensions which stick.

Example:
moz..transform = webkit..transform = transform = ...;

Re: [whatwg] fxCanvas 0.2 and some remarks about canvas spec

[Evgeny Burzak]

2010/11/15 Samuel Ytterbrink :
> hmm... Can you explain the path-object more in detail. It sounds
> interesting... but why shouldn't i just create a function that takes a
> context and do the same path commands on it instead of having a context
> taking a path object?
>

In case of >1000 path nodes , path object may save good portion of
time due to caching mechanism.
Inside  IExplorer, path is serialized  so that , I can drawing even
complicated curves without a hung.

And technical details:
CanvasPath instance has all canvas path drawings methods , plus:

append()
clone()
push()
pop()

Path segment is just an array, for ex. ["moveTo", [0,0]].

In current version nodes are saved in _stack property, but i think
CanvasPath should be special array, so that i can get n-th segment as
path[n].

Related methods in canvas context:

beginPath() - is created new path object inside context
createPath() - creates and returns path obj instance
appendPath() - appends to the current path
clonePath() - clones and returns path obj

Evgeny

Re: [whatwg] Removal of blocking script

[Garrett Smith]

On 11/15/10, Juriy Zaytsev  wrote:
> When removing [1] a long-loading script element from a document, browsers
> seem to disagree on whether such removal should affect page rendering. A
> simple test —
> http://kangax.github.com/jstests/blocking_script_removal_test/—
> shows that Opera (9.x - 11) and IE (5.5 - 9) immediately continue
> parsing
> the document upon element removal. However, in Firefox (3-4) and Chrome (9)
> the document parsing is blocked until script is loaded or times out (even
> when the actual element no longer exists in the document, has its "src"
> reference an empty string, and there exist no references to it).
>
> Does current draft explain what should happen in such case, and if it does —
> what is it (I can't seem to find it)?

This seems to be the relevant part of the spec, and it does not
address your case:
http://dev.w3.org/html5/spec/Overview.html#already-started

Though there are a few questions there.

| When a script element that is not marked as being
| "parser-inserted" experiences one of the events listed
| in the following list,

I think what was meant was "... _any_ one of the following conditions
is met, ..."

|* The script element gets inserted into a document.
|* The script element is in a Document and its child nodes are changed.
For any script, including external?

|* The script element is in a Document and has a src
| attribute set where previously the element had no such attribute.

For any script, including one with script content?

The existing discrepancy suggests that
> it's something worth codifying.
>

Regarding removal, I recall a version of Opera where removing the
script element of an external script that was not already started
would cause the script to not be evaluated. Nice feature, but not
interoperable and so totally impractical as far as web scripting goes.

> [1] Where "removing" is done through scripting (say, via Node's
> `removeChild` or analogous method).
>

innerHTML might be a good choice, to avoid memory leads in a few
browsers (ala Dojo's "garbage bin" technique).

Front end developers at Google prefer to first to set the script's src
to `null`:


Though what that accomplishes, I have no idea.

Garrett

Re: [whatwg] Treatment of negative values for li

[Ian Hickson]

On Thu, 12 Aug 2010, Aryeh Gregor wrote:
>
> The HTML5 spec doesn't say UAs should treat  different 
> from a negative value specified for any long.  For example, a get on the 
> reflected attribute li.value should return "-1".  In this test case:
> 
> 
> 
> var el = document.createElement("li");
> el.setAttribute("value", "-1");
> alert(el.value);
> 
> 
> Chrome dev, Safari 5, and Opera 10.60 all alert "-1" as expected, but 
> Firefox 4.0b3 and IE8/9 (all modes) alert "0".  In fact, Firefox and IE 
> clamp all negative values to 0.  Does anyone think this behavior is 
> valuable, or should Firefox and IE change to match the spec?  I don't 
> see any reason to treat negative values specially, if the author goes 
> out of their way to specify them.
> 
> Relatedly, only Opera seems to handle markup like
> 
> 
> 
> ...
> ...
> ...
> ...
> 
> 
> correctly.  IE8 and WebKit give 1, 2, 3, 1 (treating nonpositive value 
> attribute the same as if it were missing), and Firefox gives 0, 0, 0, 1 
> (clamping negative values to 0).  Opera gives -2, -1, 0, 1 as expected.  
> Again, I think the spec is correct here, but since browsers disagree so 
> widely, I'm asking for opinions before I file bugs against browsers.

On Thu, 12 Aug 2010, Tab Atkins Jr. wrote:
> 
> CSS implicitly states that negative list-marker values are allowed, as 
> negative numbers are discussed in the Lists module.  Opera's behavior 
> should be the correct one here.

On Thu, 12 Aug 2010, Boris Zbarsky wrote:
> 
> Just as a note, Gecko's code to imposing a lower bound of 0 on  @value> goes back to the initial implementation of attribute parsing in 
> September 1998 or so.  I doubt there was any particular reason for it 
> other than Netscape or IE compat.

Yeah, this was a conscious choice when writing this part of the spec, 
IIRC. The browsers vary wildly, as Aryeh describes, and it's not clear 
that there's a compat reason for any particular behaviour, so I specced 
the simpler and saner behaviour. I don't recall if I studied common values 
of value="" and start="" on  and . (If I did then presumably they 
weren't very common.)

I'm happy to change it if there are any compat constraints here (which 
would presumably be discovered pretty quickly once browsers move towards 
implementing this, since it affects the rendering in a pretty obvious way).

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

Re: [whatwg] Javascript: URLs as element attributes

[Boris Zbarsky]

On 11/15/10 8:15 PM, Ian Hickson wrote:

Gecko's currently-intended behavior is to do what section 6.1.5
describes in all cases except:

   
   
   
   


What does it do for those cases if it doesn't match the spec?


Note that at this point the section in question is 7.1.5: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#javascript-protocol


For  the behavior in Gecko currently is different in terms of 
what the URI of the result document of javascript: is set to.


For the others, I believe we execute them in the script environment of 
the owner document of the object/embed/applet, whereas the spec requires 
them to execute in a sandbox, as far as I can tell.


Note that there is some confusion here in terms of browsing contexts and 
, since  does expose a Document object sometimes (but 
not others) and does participate in session history sometimes, I 
believe...  So I'm not quite sure what behavior the spec calls for for 
.



I presume

Re: [whatwg] fxCanvas 0.2 and some remarks about canvas spec

[Boris Zbarsky]

On 11/15/10 7:46 PM, Aryeh Gregor wrote:

On Mon, Nov 15, 2010 at 1:19 AM, Boris Zbarsky  wrote:

2)  Casting an array of integers to an array of bytes will give you
different results on different hardware.  For example, the
integer 0x0080 when viewed as imagedata bytes is either
rgba(255, 255, 0, 0.5) (half-opaque yellow) or rgba(128, 0, 255, 1)
(fully opaque purplish blue), depending on your endianness.


That's evil.


It's compatible with how GL works, though, as I understand.


Isn't JavaScript meant to conceal machine details like
endianness?


Well, usually yes.  ;)


Couldn't we mandate that the conversion here must be
little-endian?


What does that mean in practice?  That every non-byte read from a typed 
array needs to swap byte order as needed?  I guess that's doable; mail 
the authors of 
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html 
?



 Granted that it'd be slower on ARM and such


Only some ARM.  Other ARM is little-endian.  It depends on the 
motherboard, and on some ARM devices may be a boot-time option, as I 
understand.



Or has this already become such a big and general problem


It's only a problem for this particular API which is all about raw 
memory access.  I mean... this is an API that lets you take an array of 
doubles and then examine the bytes.


-Boris

Re: [whatwg] Improve select required

[Ian Hickson]

On Thu, 12 Aug 2010, Mikko Rantalainen wrote:
> 2010-08-11 12:31 EEST: Jonas Sicking:
> > On Wed, Aug 11, 2010 at 2:03 AM, Mikko Rantalainen
> >  wrote:
> >> Stuff I don't want to see (combined with @required):
> >>
> >> - first option is always special
> >> - empty string as the value is special
> >> - option without a value is special
> > 
> > Do you consider it a problem for  to treat
> > empty string special?
> > If yes, do you think @required should be removed completely?
> > If no, why do you consider it a problem for ?
> 
> Now that you ask, I don't like  to treat empty
> string special either. I'd rather have the author specify the value that
> will be not accepted (I consider @required in the current spec to mean
> "empty string will not be accepted"). As such, I would rather have
> author specify  to disallow empty string.

In practice, what people want to say is that the user has to enter 
something in the field. I've rarely if ever seen another specific value be 
disallowed by the empty string allowed.


> A possible use case where this feature could be useful already (and
> cannot be fulfilled with @required):
> 
> 1) An user is trying to register a new user account on some system
>and uses "foo" as the nick name.
> 2) The registration form is otherwise successful, but the system
>returns with an error message saying that nick "foo" was already
>taken. In such case, the actual input field could be specified as:
> 
>   
> 
>That is, the field will be prefilled with "foo" but the field also
>contains extra information that the value "foo" will not be
>accepted in any case. The prefilled "foo" may have some value for
>the use and as a result, it does make more sense to prefil with
>"foo" instead of presenting an empty field with @required.

Sure, but there it's not just "foo" that's disallowed, it's any registered 
username, and the better UI still would be to use a script to dynamically 
check the values as the user types them (with setCustomValidity()).


> The same behavior can already be implemented with @pattern but I believe 
> that @disallow would be easier to understand to most authors. If 
> @disallow were introduced, the @required should be removed completely 
> because it doesn't provide any functionality not provided by @disallow.

I think disallowed="" would be a lot more confusing for most authors.


On Mon, 13 Sep 2010, Mounir Lamouri wrote:
> 
> I am glad that select required has been accepted and introduced in the 
> specifications. However, I have the feeling we could try to improve that 
> feature.
> 
> Currently, if multiple is set or size>1, having no option selected make
> the element suffering from constraint validation. If multiple is not set
> or size=1, the element suffer from constraint validation if the
> "placeholder label option" is selected. This is not really
> straightforward and the "placeholder label option" thing even less.
> 
> We could keep the rule "if an option is selected then the element
> requirement is fulfilled" even for non-multiple select with size=1
> select. However, we know that authors put options they don't want to be
> selected. It seems that there is two reasons:
> 1. want to show a placeholder
> 2. they don't use  so they use an option with no value to show
> a group name or a separator

Reason 1 seems reasonable. Reason 2, not so much, as there's already a 
solution for it: use . So let's ignore reason 2. Are there any 
cases of reason 1 where you might have more than one placeholder, or where 
it could not be the first one? If not, then it seems what we have now is 
simplest to explain.


> I see a few ways that may fix that:
> 1. Select elements will suffer from being missing if there are no
> options selected or all selected options have no value (empty string).
> 2. Introduce a placeholder boolean attribute for  and select
> elements will suffer from being missing if there are no options selected
> or selected options all have the placeholder attribute set.
> 3. Introduce a placeholder attribute for  which will show the
> text as a placeholder. So, there would be no pre-selected option. Thus,
> the select element would suffer from being missing if no option is selected.
> 
> Solutions 1 and 2 are backward compatible but the last solution isn't
> (ie. the placeholder text wouldn't be shown). However, a workaround can
> be found using javascript: if an option marked as disabled and selected
> is inserted as the first child of a select, it will be shown but not
> selectable (tested with Chromium 7.0.503, Firefox 4 b6pre and Opera
> 10.70). Actually, it looks like this behavior is forbidden by the
> specifications...
> 
> Solution 3, seems to be the nicest and is consistent with the other part 
> of the specifications (placeholder would be used in  and 
> ).

There's also solution 4: make the first  special if it has 
value="" (i.e. the spec's current solution).

I don't think we should rely on JS for back

Re: [whatwg] Constraint validation feedback (various threads)

[Ian Hickson]

On Wed, 11 Aug 2010, Jesse McCarthy wrote:
> Ian wrote:
> > On Tue, 10 Aug 2010, Jesse McCarthy wrote:
> > > I consider it highly desirable to have some way to differentiate 
> > > between SELECT values explicitly selected by the user and values 
> > > that were selected by default and unchanged by the user.
> > 
> > I have a note in the spec to add a feature at some point to track what 
> > controls have been changed and what haven't, but that doesn't seem to 
> > have the need for urgency that Jonas describes required="" as having, 
> > so I still think we should keep delaying that one until browsers have 
> > caught up.
> 
> Allow me to clarify.  What I'm referring to is having @required for 
> SELECT and some way to include a label, so that the user must 
> deliberately select something in order for the form to be submitted.
> 
> My comment was a response to comments you made (see below) that 
> suggested that @required is not important for SELECTs without @size or 
> @multiple, and that an initial label option, e.g.  value="">Choose One, is "invalid".
> 
> Not having @required for SELECT and simply omitting an initial "label" 
> OPTION would make the first OPTION (whatever it is) selected by default, 
> which would make it impossible to differentiate between the user 
> deliberately selecting that OPTION and simply leaving the default.
> 
> Having @required for SELECT and some way to specify a label (as you've 
> just described), so that the user must deliberately select something in 
> order for the SELECT to not suffer from being missing, satisfies the 
> need I described.

I did eventually add required="", so this is not moot, hopefully.


On Thu, 12 Aug 2010, Aryeh Gregor wrote:
> On Wed, Aug 11, 2010 at 6:03 PM, Ian Hickson  wrote:
> > The script setting the value doesn't set the dirty flag. The only way 
> > this could be a problem is if the user edits the control and _then_ 
> > the script sets the value to an overlong value.
> 
> """
> value
> On getting, it must return the current value of the element. On
> setting, it must set the element's value to the new value, set the
> element's dirty value flag to true, and then invoke the value
> sanitization algorithm, if the element's type attribute's current
> state defines one.
> """
> http://www.whatwg.org/specs/web-apps/current-work/#common-input-element-apis
> 
> That seems to say that setting via .value will set the dirty flag 
> (although setting via .setAttribute() will not).  Am I mistaken?

Hm, yes, you are correct.

I've lost track of the context for this; does the above imply that there 
is a change we need to make?


On Fri, 24 Sep 2010, Mounir Lamouri wrote:
> 
> I don't think having invalid  will be confusing for the user 
> given that the authors will have to set a message describing the issue. 
> The authors would have no reason to make this message unclear.

Your optimism about Web authors is higher than mine. :-)


> In addition,  is already semantically linked to some elements so 
> marking it invalid should be a hint that they need to be modified.
> 
> For the UI point of view, you can easily found use cases when showing 
> the output is much more convenient that highlighting all elements making 
> the output invalid. For example, in a web application to select courses 
> in a university. If there is an output showing the sum of credits which 
> has to be between 12 and 18, it sounds to be nicer to have the output 
> marked as invalid with a message explaining that the sum of credits has 
> to be between 12 and 18 than having all courses marked as invalid which 
> can be wrongly interpreted.
>
> Though, I don't think the UI is a valid point here. Shouldn't we let the 
> authors choose what UI they want to implement and just give them the API 
> to do it?

Well the setCustomValidity() API is just to set the UI; if they want to do 
their own UI then they can just do that without using the method at all.

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

Re: [whatwg] Canvas feedback (various threads)

[Ian Hickson]

On Wed, 11 Aug 2010, Philip Taylor wrote:
> On Wed, Aug 11, 2010 at 9:35 PM, Ian Hickson  wrote:
> > On Thu, 29 Jul 2010, Gregg Tavares (wrk) wrote:
> >> source-over
> >>    glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
> >
> > I tried searching the OpenGL specification for either glBlendFunc or 
> > GL_ONE_MINUS_SRC_ALPHA and couldn't find either. Could you be more 
> > specific regarding what exactly we would be referencing?  I'm not 
> > really sure I understand you proposal.
> 
> The OpenGL spec omits the "gl"/"GL_" prefixes - search for BlendFunc 
> instead. (In the GL 3.0 spec, tables 4.1 (the FUNC_ADD row) and 4.2 seem 
> relevant for defining the blend equations.)

Maybe I'm looking at the wrong specification, but I couldn't find any 
conformance requirements in the document I read on any of the pages that 
contain BlendFunc:

   http://www.opengl.org/registry/doc/glspec40.core.20100311.pdf

If there's specific text you would like to have in the HTML specification 
to replace the current definitions, I'm happy to use it. I've been unable 
to work out what such text should be, however.


On Wed, 11 Aug 2010, David Flanagan wrote:
> 
> I think that the sentence "The transformations must be performed in 
> reverse order" is sufficient to remove the ambiguity in multiplication 
> order.  So the spec is correct (but confusing) as it stands, except that 
> it doesn't actually say that the CTM is to be replaced with the product 
> of the CTM and the new matrix.  It just says multiply them.
> 
> I suggest changing the description of transform() from:
> 
> > must multiply the current transformation matrix with the matrix 
> > described by:
> 
> To something like this:
> 
> must set the current transformation matrix to the matrix obtained by 
> postmultiplying the current transformation matrix with this matrix:
> 
> a c e
> b d f
> 0 0 1
> 
> That is:
> 
>  a c e
> CTM = CTM *  b d f
>  0 0 1

I tried to update the text a little, but I didn't explicitly say 
"postmultiplying", since saying that you multiple A by B seems less 
ambiguous to me than saying that you postmultiply A with B or that the 
result should be A * B (in the latter two cases you'd have to define 
"postmultiply" and "*" respectively).


> Changing translate(), scale() and rotate() to formally define them in 
> terms of transform() would be simple, and the current prose descriptions 
> of the methods could then be moved to the non-normative green box.  The 
> current descriptions suffer from the use of the word "add" near the word 
> "matrix" when in fact a matrix multiplication is to be performed, but I 
> don't think they can be mis-interpreted as they stands. I'd be happy to 
> write new method descriptions if you want to tighten things up in this 
> way, however.

I'm happy with the text as it stands if it's unambiguous, but if you have 
any specific proposed text let me know and I'll see if it is better. :-)


On Wed, 11 Aug 2010, Boris Zbarsky wrote:
> On 8/11/10 5:42 PM, David Flanagan wrote:
> > I think that the sentence "The transformations must be performed in 
> > reverse order" is sufficient to remove the ambiguity in multiplication 
> > order.
> 
> It is?  It sounds pretty confusing to me... reverse from what?
> 
> The right way to specify what happens when composing two transformations 
> is to just explicitly say which transformation is applied first, instead 
> of talking about the algebraic operations on the matrix representations.  
> In my opinion.

Yeah, I'm not sure it's perfect as is either. If anyone has any suggested 
improvements for the text please do propose it. I'm happy to massage it 
into RFC2119-speak; unfortunately my understanding of the maths and 
graphics here is not sufficient for me to write the actual requirements.


> > must set the current transformation matrix to the matrix obtained by 
> > postmultiplying the current transformation matrix with this matrix:
> > 
> > a c e
> > b d f
> > 0 0 1
> 
> See, that makes inherent assumptions about row vs column vectors that 
> aren't stated anywhere, right?

Yes, and that assumption has in fact bitten us in the behind before.


On Wed, 11 Aug 2010, Boris Zbarsky wrote:
> On 8/11/10 4:35 PM, Ian Hickson wrote:
> > On Mon, 19 Jul 2010, Boris Zbarsky wrote:
> > > 
> > > I do think the spec could benefit from an example akin to the one in 
> > > the CoreGraphics documentation.
> > 
> > I followed your references but I couldn't figure out which example you 
> > meant. What exactly do you think we should add?
> 
> Effectively the part starting with the second paragraph under 
> "Discussion" at 
> http://developer.apple.com/mac/library/documentation/GraphicsImaging/Reference/CGAffineTransform/Reference/reference.html#//apple_ref/doc/c_ref/CGAffineTransform
>  
> and going through the two linear equations defining x' and y'.  Plus a 
> bit that says how the linear list of arguments passed to transform() 
> maps to the 2-dimensional array of numb

Re: [whatwg] Javascript: URLs as element attributes

[Ian Hickson]

On Wed, 11 Aug 2010, Cris Neckar wrote:
> 
> The HTML5 Spec is somewhat ambiguous on the handling of javascript: URLs 
> when supplied as attributes to different elements. It does not 
> specifically prohibit handling them in most cases but I was wondering if 
> this has been discussed and whether there is consensus on correct 
> behavior.

I don't understand what's ambiguous. As far as I can tell the spec covers 
all the cases you describe in detail.


On Wed, 11 Aug 2010, Boris Zbarsky wrote:
> 
> Gecko's currently-intended behavior is to do what section 6.1.5 
> describes in all cases except:
> 
>   
>   
>   
>   

What does it do for those cases if it doesn't match the spec?

I presume 

Re: [whatwg] fxCanvas 0.2 and some remarks about canvas spec

[Aryeh Gregor]

On Mon, Nov 15, 2010 at 7:46 PM, Aryeh Gregor  wrote:
> That's evil.  Isn't JavaScript meant to conceal machine details like
> endianness?  Couldn't we mandate that the conversion here must be
> little-endian?  Granted that it'd be slower on ARM and such, but
> "slower" is way better than "causes the program to break".  If the
> performance is really needed, provide extra methods that convert in
> big-endian fashion.  Then those writing programs targeted at ARM, or
> those who are willing to write different algorithms for big- and
> little-endian, can use those instead.
>
> Or has this already become such a big and general problem that fixing
> it is basically hopeless, and we're just resigned to everyone's
> scripts breaking on ARM because they were only tested on x86?

(Actually, it seems like ARM can be either little-endian or
big-endian.  Apparently it can vary based on the device, and in some
cases can even be switched on the fly.  So if everyone just hardwires
their ARM smartphones to little-endian, specifying that the function
is little-endian should be even more harmless.  Googling suggests that
at least the iPhone is little-endian.)

Re: [whatwg] fxCanvas 0.2 and some remarks about canvas spec

[Aryeh Gregor]

On Mon, Nov 15, 2010 at 1:19 AM, Boris Zbarsky  wrote:
> 2)  Casting an array of integers to an array of bytes will give you
>    different results on different hardware.  For example, the
>    integer 0x0080 when viewed as imagedata bytes is either
>    rgba(255, 255, 0, 0.5) (half-opaque yellow) or rgba(128, 0, 255, 1)
>    (fully opaque purplish blue), depending on your endianness.

That's evil.  Isn't JavaScript meant to conceal machine details like
endianness?  Couldn't we mandate that the conversion here must be
little-endian?  Granted that it'd be slower on ARM and such, but
"slower" is way better than "causes the program to break".  If the
performance is really needed, provide extra methods that convert in
big-endian fashion.  Then those writing programs targeted at ARM, or
those who are willing to write different algorithms for big- and
little-endian, can use those instead.

Or has this already become such a big and general problem that fixing
it is basically hopeless, and we're just resigned to everyone's
scripts breaking on ARM because they were only tested on x86?

[whatwg] Removal of blocking script

[Juriy Zaytsev]

When removing [1] a long-loading script element from a document, browsers
seem to disagree on whether such removal should affect page rendering. A
simple test — http://kangax.github.com/jstests/blocking_script_removal_test/—
shows that Opera (9.x - 11) and IE (5.5 - 9) immediately continue
parsing
the document upon element removal. However, in Firefox (3-4) and Chrome (9)
the document parsing is blocked until script is loaded or times out (even
when the actual element no longer exists in the document, has its "src"
reference an empty string, and there exist no references to it).

Does current draft explain what should happen in such case, and if it does —
what is it (I can't seem to find it)? The existing discrepancy suggests that
it's something worth codifying.

[1] Where "removing" is done through scripting (say, via Node's
`removeChild` or analogous method).

Best,

-- 
kangax

Re: [whatwg] Iframe dimensions

[Ian Hickson]

On Wed, 11 Aug 2010, Markus Ernst wrote:
> Am 11.08.2010 00:24 schrieb Ian Hickson:
> > On Mon, 5 Jul 2010, Markus Ernst wrote:
> [...]
> > > Example: http://test.rapid.ch/de/haendler-schweiz/iseki.html (This is
> > > under construction.) As a workaround to the height problem, I applied a
> > > script that adjusts the iframe height to the available height in the
> > > browser window. But of course the user experience would be more consistent
> > > if the page could behave like a single page, with only one scrollbar at
> > > the right of the browser window.
> > 
> > If you control both pages and can't use seamless, you can use postMessage()
> > to negotiate a size. On the long term, I expect we'll make seamless work
> > with CORS somehow. I'm waiting until we properly understand how CORS is used
> > in the wild before adding it all over the place in HTML.
> 
> A solution at authoring level for cases where the author controls both 
> pages would be quite helpful. I think of a meta element in the embedded 
> document that specifies one or more domains that are allowed to embed it 
> seamlessly in an iframe, such as e.g.:  name="allow-seamless-embedding" name="domain.tld, otherdomain.tld">
> 
> I think that this would be ok from a security POV, and much easier than 
> using CORS.

On Wed, 11 Aug 2010, Adam Barth wrote:
> 
> That feels like re-inventing CORS.  Maybe we should make CORS easier to 
> use instead?

On Wed, 11 Aug 2010, Anne van Kesteren wrote:
> 
> What exactly is hard about it?
> 
> (Though I should note we should carefully study whether using CORS here 
> is safe and sound. For instance, you may want to allow seamless 
> embedding, but not share content.)

I'd like to echo Anne's comments. If CORS is hard, then we should change 
that; if it's not, then we should use it (once we know it's solid).

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

Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations

[Ian Hickson]

On Wed, 11 Aug 2010, Boris Zbarsky wrote:
> On 8/10/10 9:11 PM, Ian Hickson wrote:
> > Specifically, this means the magic "/" string is no longer supported
> 
> Why?  That seemed like a useful feature, and not something likely to 
> break anyone out there
> 
> In particular, it allows use cases that are not possible right now (e.g. 
> reasonable postMessage from an about:blank page to a page that has the 
> same origin as the about:blank page).

On Tue, 10 Aug 2010, Adam Barth wrote:
> 
> Yeah, it seems like there's a big difference between breaking changes 
> (e.g., rejecting previously valid inputs) and non-breaking changes 
> (e.g., allowing some new, previously invalid inputs).

On Wed, 11 Aug 2010, Sigbjorn Finne wrote:
> 
> Opera has reverted targetOrigin validation back to previous in current 
> builds, but we also wouldn't mind keeping "/".

On Thu, 12 Aug 2010, Hallvord R M Steen wrote:
> 
> I stated somewhere that reverting the path validation stuff should 
> include removing the magic '/' feature, given this use case it was 
> probably better to keep '/'.

I have returned the '/' feature to its former glory without readding the 
URL path restriction.

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

Re: [whatwg] input type="location" proposals

[Ian Hickson]

On Tue, 10 Aug 2010, Diogo Resende wrote:
> On Mon, 2010-08-09 at 23:45 +, Ian Hickson wrote:
> > On Fri, 18 Jun 2010, Eitan Adler wrote:
> > >
> > > Two separate use cases
> > >
> > > 1) For entry of locations into something like Google Maps or 
> > > MapQuest. In this case the form should look as it does now (a text 
> > > box) but browsers would be able to assist you in entering locations 
> > > like it can for for emails.
> > >
> > > 2) For entry of Lat/Long coordinates which can be entered either 
> > > manually or with some kind of map like interface.
> > > 
> > > These are two separate proposals and I both could co-exist one as 
> > > type="location" and the other as type="gps"
> > 
> > Could you give some examples of sites that would use this, and 
> > examples of how they're working around the lack of this feature 
> > currently?
> 
> Any CRM with clients/suppliers/partners/people might want to define a 
> GPS location for a building/office/destination. Currently they usually 
> use a text input.

Do you have any examples? I looked around but couldn't find any. 
Everything I saw either accepted much more than just lat/long coordinates 
(e.g. Google Maps-like UIs) or used a drop-down  (to pick the 
building from a known list). Maybe I'm misunderstanding the use case.


> > On Sun, 20 Jun 2010, Eitan Adler wrote:
> > >
> > > For type="gps" I was thinking something like the following:
> > >
> > > 1) type="gps" results in a (double?) text box which takes a latitude
> > > and a longitude
> > >
> > > 2a) there is some css option that tells the text box to act like a map 
> > > instead.
> > >
> > > 2b) If the css option is on there is also some method of requesting a 
> > > "map source" this source could be any existing map provider
> > > 
> > > Then again now that I think about it some more I don't see this working 
> > > out too well.
> > 
> > Does this solve a problem that two type=number controls wouldn't solve?
> 
> type=url and type=email are here for what? We could all use type=text
> for everything.

type=url and type=email solve the client-side syntax checking problem; in 
both cases, the pattern="" attribute wouldn't be sufficient.


> > On Fri, 25 Jun 2010, Ashley Sheridan wrote:
> > > 
> > > I think it's quite a fringe case. What about things that are more 
> > > used:
> > > 
> > > * type=number - a browser could aid input with some sort of spinner
> > >
> > > * type=price - a browser could use the locale to select a monetary 
> > > format, or at least display the amount in the locale format 
> > > specified by the document itself
> > > 
> > > These are just a couple that I think would potentially be more 
> > > useful than type=location, as I see their use quite a lot. The price 
> > > one is probably more reserved to CMS's and auction sites, but these 
> > > are fairly common enough in use I feel. Number could be used for a 
> > > whole plethora of cases, such as a quantity amount in a shopping 
> > > cart, an age field in a form, or anything else where you might need 
> > > a number that wouldn't necessarily be sensible to use a type=range 
> > > for.
> > 
> > Well we have type=number. I don't know that type=price would be _that_ 
> > useful; mostly prices are output, not input.
> 
> An invoice app would want price input for products or for specific 
> invoice adjustments.

But wouldn't type=number handle that case already?

We can in the future add a "format" attribute to let you specify where the 
currency symbol goes and so on, e.g.  to get output like "$002.99" or format="%.3f CRED" to 
get output like "2.990 CRED".


On Tue, 10 Aug 2010, Diogo Resende wrote:
> Tab wrote:
> > Does a type=location offer any similar benefits over a pair of 
> > type=number inputs?
> 
> Yes, of course. Instead of a numeric keyboard (I never saw one on my 
> iphone), I could just point my current location, or select a location 
> nearby using a map or so.

In practice, maps are a really complicated thing to offer. I think it 
might be best for now to leave this up to the Bing Maps Platform, the 
Google Maps API, and so forth, than to require that browser vendors become 
experts in mapping UI.


On Tue, 10 Aug 2010, Tab Atkins Jr. wrote:
> 
> I do like the idea of being able to automatically input your current 
> location (geolocation without having to touch javascript!).

At this point it's probably best to see how the API is used before we add 
declarative alternatives. In particular, I've never seen anyone use this 
API to prime a form control; normally it's all about locating spots on 
maps and stuff like that.

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

Re: [whatwg] srcdoc="" feedback

[Ian Hickson]

On Mon, 15 Nov 2010, Tab Atkins Jr. wrote:
>
> I'm not sure why making this case marginally more convenient is 
> important.  If you're going to be pointing the frame to real pages 
> anyway, why is it a burden to supply an initial page?

It's a latency round-trip perf improvement on page load time.


> @srcdoc wasn't designed to support author-authored (hah!) pages; if 
> that's a use-case we were aiming for we would have let  display 
> its contents when there's no @src, or similar.

That would break existing pages and would not be as safe in the sandboxing 
case as srcdoc="". Providing both syntaxes seems excessive, and would 
likely result in people using the wrong one when they need security.


> Markup in attributes is a definite antipattern that we're violating in 
> this particular case only because it's the simplest thing for authors, 
> and thus the most likely to be done right.

I don't really agree that it's an antipattern. There are certainly 
situations where it's a bad idea to put markup in a string context, but 
that's primarily because it can't be syntax checked (e.g. DTDs can't check 
markup in an attribute; innerHTML is bad because there's no good way to 
syntax-check the contents of a string constant in JS; etc). If you can get 
it to be syntax-checked (as we have with srcdoc='', and as E4X does for 
XML constants in JS) then I don't really see a problem.

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

Re: [whatwg] srcdoc="" feedback

[Tab Atkins Jr.]

On Mon, Nov 15, 2010 at 1:46 PM, Ian Hickson  wrote:
> On Tue, 31 Aug 2010, Tab Atkins Jr. wrote:
>> What use-case are you trying to address that you think the suggestion in
>> this thread (make @srcdoc imply @sandbox) is incompatible with?  At the
>> moment it appears that you're confused about the goal of the change I'm
>> suggesting, but I could just be missing something.
>
> Another use case for  is the kind of thing where today
> you have to have a blank.html file to provide the initial contents of a
> frame that you'll be populating with other pages (e.g. help contents in a
> help viewer). With srcdoc="" you can now conveniently put the original
> document in the same file as the :
>
>   
>
> It's very convenient because you can then use either a script setting
> src="" directly or regular  to update the iframe. The
> latter is useful if you want the back/forward button to work, the former
> is best if you want to handle that yourself or if you ever want to be able
> to go back to the default (just remove the 'src' attribute and it'll flip
> back to the default).

I'm not sure why making this case marginally more convenient is
important.  If you're going to be pointing the frame to real pages
anyway, why is it a burden to supply an initial page?

@srcdoc wasn't designed to support author-authored (hah!) pages; if
that's a use-case we were aiming for we would have let 
display its contents when there's no @src, or similar.  Markup in
attributes is a definite antipattern that we're violating in this
particular case only because it's the simplest thing for authors, and
thus the most likely to be done right.

~TJ

[whatwg] srcdoc="" feedback

[Ian Hickson]

On Mon, 9 Aug 2010, Justin Schuh wrote:
>
> I'm working on implementing iframe.srcdoc in WebKit, and section 2.5.1 
> states:
> 
> "This specification defines the URL about:srcdoc as a reserved, though 
> unresolvable, about: URI, that is used as the document's address of 
> iframe srcdoc documents."
> 
> It seems like it would make more sense for the address to be the data 
> URL of the frame's document. This would be easier to implement in 
> WebKit, and I expect other data URL supporting browsers as well. Is 
> there some reasoning I'm missing for the decision to use about:srcdoc?

My concern is that using data: would be too easy for implementors, leading 
to some subtle yet very hard to fix bugs. :-)

For example, the origin handling for data: URLs and srcdoc="" is not 
intended to be identical (though it might be currently, I haven't 
checked). Yet if we reuse data:, it's likely that implementations will 
make it identical regardless of what the spec says. There's also the 
DOCTYPE/quirks issue, where a data: document might act differently if 
opened in its own tab than if put in using srcdoc="".


On Thu, 26 Aug 2010, Justin Schuh wrote:
>
> What should the baseURL and referrer be for a @srcdoc nested browsing 
> context?

The base URL was "about:srcdoc". Oops. Fixed to be the base URL of the 
parent document, like about:blank. (Be careful when implementing this to 
follow the chain all the way up in the case of nested srcdoc iframes.)


> The referrer seems trickier. I couldn't find the about:blank referrer 
> behavior specified anywhere, and in my testing it does not inherit the 
> creator document's referrer. However, it seems to me that maybe 
> about:srcdoc should, even if about:blank does not.

When the srcdoc="" is used with sandbox="" set without allow-same-origin, 
the Referer header is omitted.

At other times, you are correct that it wasn't well-defined (it was 
theoretically required to be "about:srcdoc"). I've updated the fetching 
algorithm to make about:srcdoc documents use the parent document's URL in 
such situations (again going up the iframe chain until it hits a 
non-srcdoc document).


On Mon, 30 Aug 2010, Tab Atkins Jr. wrote:
>
> While talking with the implementor of @srcdoc in Webkit, it came up 
> that, though @srcdoc is *designed* for use with @sandbox, the author 
> still has to explicitly add @sandbox to the  or else they don't 
> get the sandbox security model.
> 
> Can we make this automatic?  Specifically, when  srcdoc=foo> is specified (without @sandbox), it drops into the 
> sandbox security model as if  was 
> used.  If @sandbox is explicitly added, its value is instead used, so 
> the author can set the sandbox security flags if desired.
> 
> This would mean that there is no way for an author to use @srcdoc 
> *without* sandboxing.  This appears to be a minority use-case in the 
> first place (as far as I can tell, it's pretty much just useful for 
> testing purposes), but the author can always use a data: url in that 
> case.

On Mon, 30 Aug 2010, Maciej Stachowiak wrote:
> 
> I think it's better to let these remain orthogonal features. In general 
> I think it is a net negative to usability when Feature A implicitly 
> turns on Feature B. Implicit relationships like this make the Web 
> platform more confusing.

On Mon, 30 Aug 2010, Tab Atkins Jr. wrote:
> 
> While I agree with you in general, in this particular case I cannot. 
> @srcdoc wasn't designed as an orthogonal feature - it was explicitly 
> built with @sandbox in mind, to allow authors to shove generic content 
> into the sandbox without incurring a network request.  It has only niche 
> technical use outside the context of @sandbox.
> 
> Further, omitting @sandbox seems like an easy mistake to make, and one 
> that you won't realize is a mistake until an attack gets through. 
> Avoiding that sort of security model was precisely why @srcdoc was 
> designed the way it was - we want to make it hard to fail, and obvious 
> when you do.

On Mon, 30 Aug 2010, Maciej Stachowiak wrote:
> 
> Should @seamless imply @sandbox too, then?

On Mon, 30 Aug 2010, Adam Barth wrote:
> 
> I think there lots of use cases for seamless that don't require sandbox.  
> For example, suppose a site wants to show a login form on many pages by 
> only wants to implement the login logic once.  It's entirely reasonable 
> to wish to place the login form in a seamless iframe.  If we required 
> @sandbox for seamless, that would interfere with the login form working 
> properly with password managers.

On Mon, 30 Aug 2010, Ojan Vafai wrote:
> 
> I'm not convinced this is that small of a use-case even if it's not the 
> primary one. We should provide a way to turn off sandboxing if we're 
> going to make it the default for anything.

On Mon, 30 Aug 2010, Tab Atkins Jr. wrote:
> 
> Precisely; @seamless was *not* designed with the intention of always 
> being used with @sandbox.  It's just a nice feature to have for 
> s in general.  So t

Re: [whatwg] fxCanvas 0.2 and some remarks about canvas spec

[Samuel Ytterbrink]

hmm... Can you explain the path-object more in detail. It sounds
interesting... but why shouldn't i just create a function that takes a
context and do the same path commands on it instead of having a context
taking a path object?

/Samuel Ytterbrink

2010/11/13 Evgeny Burzak 

> Hi,
> I have just published new Canvas stub for IE (based on flash).  I'm
> using it in another my project - Drawform, to make it working under
> IE.
> Drawform: http://burzak.com/proj/drawform/
> fxCanvas: http://burzak.com/proj/fxcanvas/
>
> So I have some remarks about Canvas spec.
>
> I faced some troubles when using default image data, because of in old
> Explorers used extremely ineffective memory manager, so that  I made
> some tests and figure out that fastest and less memory consumption is
> array with pixel colors encoded in 32-bit integer. Here is the test:
> http://burzak.com/proj/fxcanvas/tests/data-structure-comparison.html
>
> But , the test results looks  similar for all vendors! On average the
> difference in processing speed is about 2-3 times (five times in
> Firefox 4). This is due to the fact that loops take less time (width x
> height * 4 vs. width x height) and arrays with less elements take less
> memory.  Though I realize that main idea for data structure was
> simplicity, but in this case it seems simplicity is evil, not good.
>
> Another thing is reusable canvas path.  I've added experimental class
> CanvasPath and and some related methods to Canvas context.
> For example:
> var p = new CanvasPath() // I think first argument can be string from
> SVG "d" attribute
> p.moveTo(0, 0)
> p.lineTo(10, 20)
> ctx.beginPath()
> ctx.appendPath(p)
> ... and so on. If you are interested in it, I can describe my idea
> futher...
> This is quite useful thing, at least for me.
>
> Evgeny
>