Re: [whatwg] Stability of tokenizing/dom algorithms

2008-12-16 Thread Iñigo
 Edward Z. Yang:
   Sounds good, since HTML4 is a strict subset of HTML5 (correct me if I'm
   wrong?)

 Ian Hickson:
  Mostly, yes. (There are exceptions, but they're not things you'd really
  want to be using anyway, e.g. obscure SGML features.)

 Note though that it's not possible to write a document that is both
 valid HTML 4 and HTML 5, since they both require a different DOCTYPE to
 be used.


That's right, Cameron, but you could change nothing more than the DOCTYPE in
order to validate
if you have choosen a right subset of HTML 4.x.

iñigo




 --
 Cameron McCormack ≝ http://mcc.id.au/




-- 
Iñigo Medina García
Tecnología

http://www.toprural.com
Tu guía de turismo rural


Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Nils Dagsson Moskopp
Am Dienstag, den 16.12.2008, 14:22 + schrieb Philip Taylor:
 On Tue, Dec 16, 2008 at 2:15 PM, Nils Dagsson Moskopp
 nils-dagsson-mosk...@dieweltistgarnichtso.net wrote:
  As I said, invalid input should be rejected in the first place. When I
  write a blog post, I usually catch errors like this when I click on the
  preview button and its all yellow.
 
 But you still accept user input that can lead to ill-formed output,
 like in http://blog.dieweltistgarnichtso.net/?s=%ef%bf%bf :-)
 (That particular case probably doesn't affect anyone other than the
 user who enters that URL, but it's a pain whenever the user input is
 displayed back to other users or shown in admin interfaces, and very
 few people seem to implement it correctly in practice.)
Please, its Wordpress ! Those are the people that use eval() when
parsing input. I already have hacked a bit and will no doubt do
something about input as soon as my HTML5 theme based on sandbox is
ready. In the meantime, don't input this character in the comments, I've
not really thrilled to see that stuff implode.

Oh and btw, my own web app *will* reject input and / or normalize it
(whenever it is done, with which I mean: I first have to sort out some
issues with the database ...).

Greetings
-- 
Nils Dagsson Moskopp
http://dieweltistgarnichtso.net



Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Tab Atkins Jr.
On Mon, Dec 15, 2008 at 8:36 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
 On Mon, Dec 15, 2008 at 8:02 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 You're not Nicholas. We don't know if that is what Nicholas expects
 his HTML to do or if he is expecting something else. In absence of an
 example, I can't do much more than guess. I cannot expect your
 assumptions to be correct.

 Well, of course, but you sent the message to the entire group, so you
 should be ready for answers from the whole group.  ^_^

 You've not stated how creating invalid HTML can control scripts.
 Having an interest in scripting, I would like to know how this works.

 Dude, come on.  You're trying to poison the dialogue here.  The point

 Instead of a complaining about my intentions, why don't you post an
 example that shows the problem (demonstrate need), how the problem is
 overcome (the invalid HTML solution), and what browsers actually do?

Sorry, I thought I was demonstrating it, but I guess I was being too
general.  An example I know of off the top of my head is the jQuery
Validation plugin[1].  If you can uniquely identify the elements in
your form (either through #id or other structural means) and can place
scripts (not always possible for end-users of a CMS application or
something), you can tell the plugin exactly how to validate each form
element when you first invoke it, through the script.

If either of these are false, though, you can instead place the
attributes on the element itself, and the script will read them off
while it's executing.  Many of the common ones can be easily and
usefully embedded in @class (giving an element a class of required,
frex, can also help with styling), but using the more complex
validation routines in @class requires you to embed JSON, which is a
horrible hack (as the parser doesn't recognize this and just tokenizes
it as multiple oddly named classes).  The script reads the entire
class attribute as a string and parses this effectively, but it can
have unintended consequences.

Instead, you can embed these more complex routines in custom
attributes.  jQuery has a plugin that allows easy access to these in a
cross-browser way (the Metadata plugin[2]).  Doing this allows you to
embed complex validation instructions on the elements themselves in an
easily human-readable and human-writable format, with an absolute
minimum of side-effects (generally, *no* side effects).

 I've seen code that has invalid attributes. These attributes won't
 always have the same effect as the author wanted them to. Not all
 authors expect the same thing from their invalid HTML.

 Recent c.l.js discussions have included examples of page author using
 a named element where that element does not support the name
 attribute, e.g. span name='fred'. The author had expected the
 element to be included with getElementsByName, but it wasn't. (not the
 first time someone has expected nonstandard behavior from an
 attribute). I've seen other uses of invalid HTML that did what the
 author wanted to in most cases.

This is (one reason) why I objected to using the blanket term invalid
HTML, because it covers far more than what we're talking about here.
*I*, and Nicholas I'm sure, are referring solely to using *custom*
attributes.  In this example, you're talking about hacking an existing
attribute, and being surprised at the outcome.  (I find it likely that
the author was trying to use @name as a replacement for @class, hoping
to lean on the already-implemented getElementsByName function rather
than rolling his own getElementByClass).

 As to how custom attributes can help control scripts, look into any
 decent javascript plugin.  Many of them utilize some form of metadata

 What is a javascript plugin?

 The param element is designed for associating data with a plugin,
 such as a swf movie. Is this an allusion?

I apologize; I thought the term was widespread enough.  When using
things like the jQuery library, additional scripts built on top of it
are termed 'plugins'.


In general, though, the case for custom attributes is identical to the
case for JS expando attributes, which *have* been around for a long
time.  It can be very useful for a script to store arbitrary data on
an element, and the simplest way to do this in many cases is by
creating a new expando attribute.  Custom attributes is nothing more
than a way to embed this information in the static HTML as well, so
that it can be authored and carried around independently of the
script, or provide good 'initial values' to the script.

And again, as stated previously, this discussion *has* already been
settled.  We have the data-* attributes as an officially blessed way
to provide custom attributes on HTML, and as a recommended way to add
expando attributes via JS.  What I'm talking about is only 'invalid
HTML' in HTML4 - it's perfectly valid html5 now.

1: http://bassistance.de/jquery-plugins/jquery-plugin-validation/
2: 

Re: [whatwg] Web Workers Draft

2008-12-16 Thread Ian Hickson
On Tue, 9 Dec 2008, Douglas Mayle wrote:

 I was taking a look at the Web Workers Draft ( 
 http://www.whatwg.org/specs/web-workers/current-work/ ), and I couldn't 
 find any mention of cross domain workers.  I've read a bit about 
 relaxing domain restrictions on documents, but worker's don't seem to 
 have a document object. I also see the details about location, but I 
 haven't found any information about relaxing the origin.  Is there any 
 plan to allow cross-domain workers? I'm currently using them in Gears to 
 enable a shared storage solution, and would like to be able to migrate 
 one day to official standards.

On Tue, 9 Dec 2008, Douglas Mayle wrote:

 After sending this, it occurs to me that at the worst, I could have a 
 separate document to marshal access to a cross domain web worker.  It's 
 an extra hoop to jump through, but at least it would work.

Currently, scripts run in the origin of their main script, and the main 
script of a worker has to be same-origin with the creator of the script. 
We might change this once we have implementation experience, but in 
general having an iframe doesn't seem like a great burden for now.

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


[whatwg] A few hints on html5 - part 1

2008-12-16 Thread Calogero Alex Baldacchino
Let me suggest a few hints on html5 specs, maybe some hints will be 
minor or less important, maybe some others might be useful for a 
somewhat next version of these specifications. Let me also apologize if 
the following points have been yet discussed and I'm missing such 
discussions, or if I've misunderstood any part of the specs. -- this was 
a longer message, but the list bot refused it, thus I'm splitting it 
into a few messages (and thus the subject, part 1 etc.)


First, maybe the less relevant: in the Script execution contexts 
section a request is made for some couple of terms other than 
with/without script. OK, let me suggest scriptable/unscriptable or 
reachable/unreachable by script, for instance. Just a simple hint, no 
more.


The former suggests me a possible (partial) solution for the events 
section question about events handling for non active or browsing 
context-less documents: being script execution not allowed in such 
situations, we could state that any event exclusively thought for script 
interaction should never fire, unless any valid motivation arises to let 
the event fire and be dispatched to the corresponding handler(s), and in 
such a case the whole mechanism of deciding whether script execution 
must be allowed or not should be revisited. Otherwise, if any script 
related resources are thought to be kept alive in a somewhat frozen 
state (in example, in a previously active document, a connection buffer 
with last received, not yet elaborated content, the connection itself to 
be re-established, or its status), then any related event could fire and 
be frozen in a pending state, or just be frozen or pending, 
meaning in a before firing state, ready to fire (and be dispatched) as 
soon as the document enters a scriptable state (i.e. becomes active or 
gains a browser context).


Furthermore, the event loop and task queue definitions suggests me 
that a somewhat user agent could implement a sort of all-in-one 
mechanism to handle together (maybe for an improved interaction?) both 
implementation-related and script-related events, i.e. queueing together 
both types of event (or the related tasks), with a somewhat precedence 
rule between them, or even, in some cases, the very same event/task to 
be first handled by the underlying implementation, then passed 
(wrapped?) to the script specific mechanism (for instance, when a 
document, or an object inside a document, is fully loaded, a native 
load event is generated to increment/complete the document rendering 
and then it is wrapped and sent to any script related handler). In such 
a case, the specification could establish, for clearness sake, that only 
implementation related events must fire, if meaningful for the 
implementation in a non-scriptable context (an inactive or 
context-less document), while any script related event (even the same 
wrapped event, after the underlying elaboration) must either be 
discarded (it does not fire) or be frozen (if applicable) for a further 
possible resuming. Might such a clarification be helpful for such an 
(unrealistic? strange? possible?) implementation, in order to avoid or 
reduce confusion or possible side effects?


Anyway, such considerations might perhaps either be left to the user 
agent implementation, or be deferred to a next version of html5 specs...


For the How do we allow non-JS event handlers? concern, let me 
distinguish two different cases:


1) an event handler content attribute is set in the markup:
Let's assert it must conform to the ECMAScript FunctionBody production 
rules by default, unless another language is stated elsewhere as the 
default scripting language for the whole document or for a particular 
element.


As for the whole document, a meta tag could be used, such as 'meta 
http-equiv = Content-Script-Type content = 
a_valid_scripting_mime_type /' or the alike. If the declared 
mime-type is not supported, it could be defaulted to the ECMAScript one.


For the element by itself, an attribute could be added both to the 
markup and the DOM, either to describe a script language valid for all 
the script content attributes (i.e. 
'defaultscript=appropriate_mime-type'), or to define a list of valid 
mime-types (i.e. 'acceptedscripts=first_mimetype;second_mimetype'). In 
the latter case, for each parsed script content attribute, the first 
declared mime-type should constrain the production rules, or be skipped 
if not supported, using the next mime-type upon failure or after 
skipping an unsupported one; if all sequentially applied production 
rules fail, let a SYNTAX_ERR arise (or any other appropriate 
error/exception); if no mime type is supported, the default script 
language rules are applied (if not listed, that is, yet tried in the 
previous step), and if even this fails, let an appropriate 
error/exception (maybe the SYNTAX_ERR itself) arise. For the sake of a 
graceful degradation, the script content attribute whose production has 
failed could be 

[whatwg] A few hints on html5 -- part 2

2008-12-16 Thread Calogero Alex Baldacchino

About the RemoteEventTarget interface

The removeEventSource() method is provided to remove one instance of a 
source (one matching URL) per invocation, but no way is defined to know 
whether other instances are yet listed, or if the operation succeeded. 
Maybe such method could return a boolean value telling whether the 
operation was successful, so that, i.e., all matching URLs could be 
removed at once in a simple iteration calling the method until it 
returns false. Maybe a remove all method could be considered too.


I guess a single RemoteEventTarget can list several time the same remote 
source to take advantage of more than one connection (maybe non-http) to 
fetch different resources and/or to ask for different server-side 
computations in parallel; however, it might be helpful to define either 
a mechanism to remove a precise source (i.e. passing an index or the 
alike, not just the URL) instead of removing a source on a per enter 
position basis (that is, the first encountered is removed, as could be 
thought) or a precise choice algorithm (i.e., skipping an active URL), 
since without neither a precise targeting nor a precise algorithm a 
somewhat user agent could remove the wrong url upon request, and so 
closing for instance a connection with a pending get operation: one of a 
RemoteEventTarget message event handlers could receive an end event 
and try and close its connection, but the implementation, by mistake, 
could remove a source URL used by another handler waiting for a 
response, or the method could be invoked from a piece of code outside 
any handler, and so the choice might become more difficult. Otherwise, 
an algorithm should be defined to switch the communications from a 
closed source to another still active.


According to the previous hint, let me suggest the following:
- a streamed event should be associate to a numerical index representing 
either the relative position (i.e. indicating it's the Nth occurrence) 
or the absolute position of the source URL in the RemoteEventTarget list 
of event sources; for this purpose, the last event id attribute should 
be considered unreliable;


- a removeEventSource() method variant is provided accepting the index 
as a second parameter;


- when the removeEventSource is invoked without the index argument (i.e. 
to iteratively remove all occurrences), the following algorithm is applied:

1) if the URL resolution fails return false and abort these steps;
2) pick the first occurrence of src argument in the list of event 
sources, if any;

3) if no occurrence has been found return false and abort these steps;
4) if a remove source as possible task or a remove source immediately 
task has been tailed for src, stop execution and return true;

5) queue a remove source as possible task and return true;

- when the removeEventSource is invoked with the index argument follow 
the previous steps but change step 2) and 3) as follow:
2) pick the source occurrence in the list of event sources corresponding 
to the index argument and compare it with src argument;

3) if comparison fails return false and abort these steps;

a remove source as possible task is a task delegated to remove the 
source URL from the list of event sources and to close the related 
connection as soon as any pending event is completely received and 
dispatched to every listening handler and no message has been post to 
the remote server (otherwise wait for the response event); a remove 
source immediately task is a task performing the same operation but 
without waiting for pending events: as soon as the task is executed, the 
event source is eliminated.


- a couple of removeEventSourceNow() methods is provided with the same 
characteristics of the previous, but queueing a remove source 
immediately task.


- if needed, an appropriate task source is provided.

Regards, Alex


--
Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP 
autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
Tom Raider Anniversary ora sul tuo cellulare! Entra in azione!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8277d=16-12


[whatwg] A few hints on html5 - part 3

2008-12-16 Thread Calogero Alex Baldacchino

About the cross-document messaging

Let's consider the following scenario. A somewhat productivity suite (or 
any sort of web applications collection) is made up of a few different 
top-level/auxiliary browsing contexts - let's call each one a module - 
eventually from different origins, and exploits cross-document 
communications to some extent, i.e. to delegate some computations or 
some shareable communications with a remote server; each module is 
independent and can instantiate the proper auxiliary module(s).


Here we are: as far as the modules are instantiated as auxiliary 
browsing contexts of one other module (i.e. through a call to 
'window.open()'), communications are easily established, but what if any 
module is instantiated by the user as a separate top-level browsing 
context, i.e. opening a new tab or window and recalling the module 
document from a bookmark? I'd suggest the following:


- a mechanism is established to get access, without any restriction, to 
every browsing context for which the user agent can individuate a 
non-empty, non-null, non-undefined name attribute, at least with the 
capability to let cross-origin access to the postMessage() methods. 
For instance, the specifications could clearly state that the Window 
open() method must return an existing window reference with the 
specified name when invoked with an empty string or null as URL 
argument, with no security restriction (security restrictions should 
apply just to the returned window object properties). When more than one 
browsing context share the same name, actual rules for choosing a 
browsing context given a browsing context name should apply to choose a 
first result, without checking if current browsing context is allowed to 
navigate that browsing context; it might be helpful to get instead a 
list of all browsing contexts with the same name, obtained as follow: a 
Window object is created as a pseudo unit of browsing contexts, so that 
each browsing context is reachable both by invoking the XXX4() method 
and by accessing the frames property; each browsing context is wrapped 
in a Window object with 1)accessible postMessage() methods, calling the 
wrapped window ones, 2)an accessible parent attribute referring to the 
grouping Window object, 3)a self attribute referring to the wrapped 
object, accessible if access to the wrapped object is allowed by 
security restrictions, 4) access denied, without any exception/error 
arising, to any other method/attribute; the first member of the group 
(i.e. the object returned by calling XXX4(0) on the grouping Window) is 
the wrapper for a Window object determined by the rules for choosing a 
browsing context given a browsing context name (i.e. the most recently 
opened, or focused, or the most related with the open() method caller 
browsing context) and is returned.


- optionally, a few postMessageToAll() methods (with about the same 
arguments of the postMessage() ones) could be considered to let any 
browsing context to communicate, through its own Window interface, 
either to any other browsing context (eventually allowing communications 
from current browsing context as source, see below), or to every 
browsing contexts constrained by the same name (passed as, let's say, 
first argument), or to every browsing contexts with the same domain 
(specified, let's say, as the second argument).


Let's consider another scenario. A site (perhaps a blog) embeds content 
from a forum (or any social network), and uses script code to connect to 
the remote server and keep it's content up to date, but also to notify 
the user about any changes in other contents the remote server holds as 
subscribed (this scenario can be extended to mail notifications in the 
previous example of a productivity suite, or to a groupware). When the 
user navigates other documents from the site in different browsing 
contexts, each one is aware of the others (perhaps establishing a 
connection through a call to postMessageToAll, or by getting a reference 
by name); to avoid increasing the number of connections per server, any 
successive document navigated as a standalone browsing context (after 
the first or after a certain number) won't connect to the remote server, 
but will communicate with the document having an active remote 
connection. That is: the first navigated document maintains a remote 
connection and receives notifications as remote events; if it is fully 
active, the notifications are shown to the user, otherwise a message is 
sent to any other known document capable to handle the notification, 
hoping one is fully active; the first document becoming fully active 
handles the messages and notifies to the other documents that any 
required operation has been performed; when the remote events handling 
document(s) are to become no more active (i.e. they unload), a message 
is sent to the remaining documents so they can decide (somehow) who's 
the next dispatcher.


The above could 

[whatwg] A few hints on html5 - part 4

2008-12-16 Thread Calogero Alex Baldacchino

Miscellaneous


The Window interface open method accepts a features argument for 
historical (and backward compatibility) reasons, which, as stated, has 
no actual effect. I was considering the opportunity, instead, of 
maintaining the old functionality as an alternative and redundant 
implementation of the make application state. That could work this 
way: any browser feature set disabled in the features string is disabled 
and not shown in the newly opened window, BUT, a somewhat element, 
clearly being part of the browser application, is provided to let the 
user enable any hidden feature (either altogether, or one by one), so to 
reset the normal application condition; when a browser interface 
component is hidden, any related key binding is freed from usual 
capture, and redirected to the window active document, so that a full 
standalone behaviour is transparently shown to the user (the reset 
element should never be disabled), while when that component is 
re-enabled its normal behaviour is re-established; if the application is 
going full-screen the user is clearly advised about this and allowed to 
block the operation (in the case the operation is allowed, the reset 
element should become floating and maybe half-transparent -- I was 
thinking on a possible, future 2D or even 3D web based game...).


-

Current draft provides a few overloaded methods (like postMessage() 
variants) differing for the number, type and order of their attributes. 
A first concern could arise on the choice to overload functions in IDL 
interfaces, since any of the possible supported/supportable script 
language could not provide such a feature, making implementation more 
difficult; however, this could be a minor concern, both since a script 
with C-like syntax (as most are) usually let functions be overloaded, 
one way or another, and because a different kind of language, not 
providing such, could overcome the problem by defining methods with 
slightly different names and binding them to the appropriate interface 
(but this would lead maybe to a longer learning period and to possible, 
successive even greater difficulties whether such names would clash with 
future standard names). Maybe the parameters order and number could be 
another concern, since a script language could (like JavaScript does) 
allow functions overloading by varying the number of passed arguments, 
without caring about arguments types, and leaving to the inner code any 
checking and choice of what to do (that's closer to a C++ function 
declaration with default arguments, than to a full overload); this is 
not a real problem, but perhaps a little improvement in current specs 
might result from changing the arguments order so that the arguments 
list of an overloaded method's two variant, when compared, is equal for 
the first 'x' arguments, where 'x' is the length of the shortest list, 
since this could reduce the translation work the script engine must do 
before calling the underlying implementation (i.e., it could be a 
slightly easier casting of the arguments to their correspondent native 
types, without any previous checking for the right type, before calling 
the interface native implementation - the point is: a check is likely to 
be done by the casting routine(s), so couldn't it be avoid before 
casting?). Furthermore, any language missing the overload semantics 
could expose just one method with the whole list of possible arguments, 
corresponding to the idl declared method with the longer list, and I 
think that defining idl methods with some care for arguments order would 
be a neater choice.


-

Current browsers provides facilities to parse xml code (either the 
DOMParser object or a DOM Load and Save Parser). All fail with html tag 
soup, so if for any reason a somewhat string of html code must be 
parsed to manipulate its DOM representation before taking any action, a 
workaround must be found (i.e. calling 
document.implementation.createHTMLDocument() and somehow inserting the 
string into such fake document, then getting the DOM structure - this 
could be quite unreliable too, as a parsing alternative, if any script 
code in that string were executed). Since one of the goal of html 5 
specifications is the definition of a standard parser, with a standard 
parse error management, maybe the opportunity of exposing an 
html-specific parser (skipping script execution) through the DOM might 
be considered.


-

Current draft states a script element set through the innerHTML property 
is not executed at all, while it is when added by calling 
document.write() (what about insertAdjacentHTML()?). However, I think 
that allowing script execution in the former case would made of the 
innerHTML property a truly live one, with some possible benefit: i.e. it 
could be a way to insert new script elements into the document head 
section from outside the head element (i.e. from an event listener on an 
eventsource, to dynamically 

Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Giovanni Campagna
2008/12/16 Nils Dagsson Moskopp 
nils-dagsson-mosk...@dieweltistgarnichtso.net

 Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna:

  (The same behaviour can be achieved also with a @namespace rule,
  putting non-standard attributes in an application-specific namespace)

 Since data attributes do not exist as of yet, I believe people would use
 XML for namespaces, so I somehow don't see your problem.

 1) data attributes are not standarized and the dataset DOMStringMap is
not present, but if you try using them with domCore interfaces they should
work (i haven't tested though)
2) XML serialization is much more difficlut to implement than old HTML, and,
as i said before, in many cases it is not implementable at all: probably a
company which hosts user-generated content such as blogs or forums won't
like that no browser can display his pages because someone wrote invalid
html
even the most experienced can mis-type code, and in that case the only way
to solve is to manually edit source using a plain text editor, which is not
possible with user-generated content
3) the dataset DOMStringMap is a quite useful way to enumerate attributes
explicitly marked as application data


Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Nils Dagsson Moskopp
Am Dienstag, den 16.12.2008, 14:32 +0100 schrieb Giovanni Campagna:

 (The same behaviour can be achieved also with a @namespace rule,
 putting non-standard attributes in an application-specific namespace)

Since data attributes do not exist as of yet, I believe people would use
XML for namespaces, so I somehow don't see your problem.

-- 
Nils Dagsson Moskopp
http://dieweltistgarnichtso.net



Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Nils Dagsson Moskopp
Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna:
 Browser assume that author knows XML because he's put an application/*
 +xml mime type.
 On the other hand, this assumption cannot be done for blogger, who
 aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs
 (they're not expected to know about what or w3c either)
Then they shouldn't write XHTML in the first place ... there *are* some
good autoformatters which handle stuff for you (think: newline - br/,
two newlines - paragraph). Also, WYSIWYG editors should *not* gave
you the oppontuniy to mess up your code.

  Could not save you post, invalid XML markup (Mismatched end tag,
 expecting img, found /p)
  See W3C XML1.1 specification (link to  XML spec) for further
 information about this.
 Or just Not well-formed (attribute values must be encoded in double
 quotes)
The current error messages are crap, that is totally right. They could
certainly be more user-friendly.

 You have no page, thus no way to edit!
The admin interface should be always well-formed, having the offending
portion in a textarea (or similar) for easy editing and an iframe
for viewing.

-- 
Nils Dagsson Moskopp
http://dieweltistgarnichtso.net



Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Giovanni Campagna
2008/12/16 Nils Dagsson Moskopp 
nils-dagsson-mosk...@dieweltistgarnichtso.net

 Am Dienstag, den 16.12.2008, 15:38 +0100 schrieb Giovanni Campagna:
  Browser assume that author knows XML because he's put an application/*
  +xml mime type.
  On the other hand, this assumption cannot be done for blogger, who
  aren't expected to know XML / XML 1.1 / XHTML 1.0 / HTML5 specs
  (they're not expected to know about what or w3c either)
 Then they shouldn't write XHTML in the first place ... there *are* some
 good autoformatters which handle stuff for you (think: newline - br/,
 two newlines - paragraph). Also, WYSIWYG editors should *not* gave
 you the oppontuniy to mess up your code.

In a forum you usually write BBCode (or similar), that is server-side parsed
with the same hacks as the HTML5 parser, while in other context it is
definitely more powerful to write directly HTML
Secondly, this:
pClick on my icon a href=somewhere.htmlimg width=88 height=15
src=myicon.png/p
is valid HTML although not valid XHTML. Do you mean this with messing up
your code?


   Could not save you post, invalid XML markup (Mismatched end tag,
  expecting img, found /p)
   See W3C XML1.1 specification (link to  XML spec) for further
  information about this.
  Or just Not well-formed (attribute values must be encoded in double
  quotes)
 The current error messages are crap, that is totally right. They could
 certainly be more user-friendly.

Have you got any ideas?


  You have no page, thus no way to edit!
 The admin interface should be always well-formed, having the offending
 portion in a textarea (or similar) for easy editing and an iframe
 for viewing.

In any case, it is not allowable for companies to have their site down
because of an user, even for just few minutes (if your lucky and find bug
immediately)


Re: [whatwg] Terminate a Worker algorithm

2008-12-16 Thread Ian Hickson
On Tue, 16 Dec 2008, Alexey Proskuryakov wrote:
 
 Dec 16, 2008, в 9:43 AM, Ian Hickson написал(а):
 
   1) The algorithm assumes that a WorkerGlobalScope exists, and 
   doesn't specify what happens if it is invoked before 
   WorkerGlobalScope is created (e.g. if the script is still being 
   loaded, or the scope is being created, but Worker.terminate() is 
   called from JS). I think that the right behavior is to re-invoke the 
   algorithm after the scope is created, because it may be too late to 
   prevent its creation.
  
  It can't be invoked before the WorkerGlobalScope is created. The 
  WorkerGlobalScope is created before the constructor returns the Worker 
  object.
 
 This means that creating a Worker would involve running a nested run 
 loop, waiting for WorkerGlobalScope to be created in another 
 thread/process. I think that WorkerGlobalScope needs to be created 
 asynchronously. The above is the only observable difference with 
 synchronous creation that I could find, so I think that requiring 
 synchronous operation is unnecessary.

Sure, implementation-wise there is a race condition to take care of. But 
the behavior to implement is well-defined.


   2) Events in WorkerGlobalScope event queue are dropped when 
   terminating a worker, but messages posted to Worker are not. I think 
   that the expected behavior is that after calling Worker.terminate(), 
   no messages will be dispatched to worker's event listeners.
  
  Once 'closing' is set to true, the queue discards any additional 
  tasks.
 
 There is no closing flag on the Worker object, it's only defined on 
 WorkerGlobalScope as far as I can see.

Oh I see what you're saying. Sorry, I misunderstood. I guess we could 
empty the queue of messages once a worker is terminated... Ok, done.

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

Re: [whatwg] Error propagation in child workers

2008-12-16 Thread Ian Hickson
On Thu, 27 Nov 2008, ben turner wrote:
 
 I just got around to fixing the error handling in our worker 
 implementation and realized that the spec is a little vague here, 
 especially when workers are created within workers. This is what we have 
 now, and Jonas and I both find it intuitive and useful:
 
 Assuming we have a page that creates a worker (let's call this worker 
 the parent), and it creates a new worker (the child).
 
 First, we currently use a MessageEvent object for our 'error' events 
 where the 'data' property contains a string representing the exception, 
 but we don't really like that. We'd like to propose that we use a new 
 type of event, ErrorEvent, that looks like this:
 
   interface ErrorEvent : Event {
 readonly attribute DOMString message;
 readonly attribute DOMString filename;
 readonly attribute unsigned long lineno;
   }

How do you feel instead about using the same mechanism on Worker objects 
as we currently use on Window for error handling?

Specifically, window.onerror is called as a function with three arguments 
when an error occurs. I'm suggesting that when a worker has an unhandled 
exception, we fire Worker.onerror outside the worker, again with three 
arguments (message, script url, line number). If the function return 
false, then the error reporting is quenched; otherwise, it is reported in 
the warning console.

For shared workers, we could either support this in the same way, or 
always report the errors to the console and not have a way to catch them.

Or, we could not have any ways to catch these unhandled exceptions at all. 
I'm interested in feedback from other implementors here -- is this 
something you are interested in?

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


Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Nils Dagsson Moskopp
Am Dienstag, den 16.12.2008, 15:02 +0100 schrieb Giovanni Campagna:

 2) XML serialization is much more difficlut to implement than old
 HTML, and, as i said before, in many cases it is not implementable at
 all: probably a company which hosts user-generated content such as
 blogs or forums won't like that no browser can display his pages
 because someone wrote invalid html
It is not hard to reject input if its not well-formed. If browsers can
do it, why shouldn't web apps be able to ?

 even the most experienced can mis-type code, and in that case the only
 way to solve is to manually edit source using a plain text editor,
 which is not possible with user-generated content
As I said, invalid input should be rejected in the first place. When I
write a blog post, I usually catch errors like this when I click on the
preview button and its all yellow.

-- 
Nils Dagsson Moskopp
http://dieweltistgarnichtso.net



Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Nils Dagsson Moskopp
Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna:
 Maybe so-called invalid HTML attributes are not the only solution,
 but in my opinion it is a simple way to embed metadata within any
 element.
What metadata are you talking about ? Microformats already exist.

 Personally I prefer the latter (XML) solution, but there are context
 where using XML serialization is not possibile (for example in user
 generated content) so there is a definite need for a SGML way to add
 custom attributes without conflicting with standards.
HTML5 is not derived from SGML anymore.


Greetings
-- 
Nils Dagsson Moskopp
http://dieweltistgarnichtso.net



Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Giovanni Campagna
2008/12/16 Nils Dagsson Moskopp 
nils-dagsson-mosk...@dieweltistgarnichtso.net

 Am Dienstag, den 16.12.2008, 14:14 +0100 schrieb Giovanni Campagna:
  Maybe so-called invalid HTML attributes are not the only solution,
  but in my opinion it is a simple way to embed metadata within any
  element.
 What metadata are you talking about ? Microformats already exist.


I'm talking of any data that is related semantically to element and should
not be printed to the user or interact with default browser behaviour. There
is an example in the HTML5 spec of an element representing a spaceship in a
browser game, with data- attributes to provide fire / armour values
Imagine the spaceship has class spaceship, then i can write the following
css:
.spaceship:after {
display:block;
height: 10px;
width:  attr(data-attack,px);
background-color: red;
color: white;
text-align: center;
content: Attack value  attr(data-attack,string);
}
.spaceship:after:after {
display:block;
height: 10px;
width:  attr(data-defence,px);
background-color: green;
color: white;
text-align: center;
content: Defence value  attr(data-defence,string);
}
(The same behaviour can be achieved also with a @namespace rule, putting
non-standard attributes in an application-specific namespace)


  Personally I prefer the latter (XML) solution, but there are context
  where using XML serialization is not possibile (for example in user
  generated content) so there is a definite need for a SGML way to add
  custom attributes without conflicting with standards.
 HTML5 is not derived from SGML anymore.

My fault, I meant the HTML serialization of HTML5.
Giovanni Campagna


Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Giovanni Campagna
Maybe so-called invalid HTML attributes are not the only solution, but in
my opinion it is a simple way to embed metadata within any element.

Imagine that such markup is then passed to a web application through XHR. In
that case scripts aren't parsed and executed. In this case you have three
ways to attach a behaviour:

2) on-event standard attributes (but they not performant since they're
parsed every time the event fires and the cannot include chars like  or ,
they need to be escaped)
3) assigning a class and some metadata using data-, then
getElementsByClassName and addEventListener

The same with CSS: you can use style for each element or data-
attributes queried by attr()

For what concerns browser support, these attributes are at all part of the
DOM tree, so I can pass their names to getAttribute and setAttribute, but
they don't get any special interface.

It's the same in the XML serialization with different application-specific
namespaces: they use only DOMAttr interface defined in DOM3Core and they're
not part of any infoset (not part of ID list or NAME list)

Personally I prefer the latter (XML) solution, but there are context where
using XML serialization is not possibile (for example in user generated
content) so there is a definite need for a SGML way to add custom attributes
without conflicting with standards.


Re: [whatwg] Stability of tokenizing/dom algorithms

2008-12-16 Thread Edward Z. Yang
Ian Hickson wrote:
 Mostly, yes. (There are exceptions, but they're not things you'd really 
 want to be using anyway, e.g. obscure SGML features.)

Are these exceptions, by any chance, documented somewhere?

Cheers,
Edward


Re: [whatwg] Thoughts on HTML 5

2008-12-16 Thread Ian Hickson

I tried following this thread but I can't find what I would need to change 
in the spec to address the feedback so far. If this feedback relates to 
requests for the spec, please elaborate on exactly what it is that should 
change -- thanks!

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


Re: [whatwg] Stability of tokenizing/dom algorithms

2008-12-16 Thread Ian Hickson
On Tue, 16 Dec 2008, Edward Z. Yang wrote:
 Ian Hickson wrote:
  Mostly, yes. (There are exceptions, but they're not things you'd really 
  want to be using anyway, e.g. obscure SGML features.)
 
 Are these exceptions, by any chance, documented somewhere?

   http://wiki.whatwg.org/wiki/Differences_from_HTML4
   http://dev.w3.org/html5/html4-differences/

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


Re: [whatwg] Error propagation in child workers

2008-12-16 Thread Jonas Sicking

Ian Hickson wrote:

On Thu, 27 Nov 2008, ben turner wrote:
I just got around to fixing the error handling in our worker 
implementation and realized that the spec is a little vague here, 
especially when workers are created within workers. This is what we have 
now, and Jonas and I both find it intuitive and useful:


Assuming we have a page that creates a worker (let's call this worker 
the parent), and it creates a new worker (the child).


First, we currently use a MessageEvent object for our 'error' events 
where the 'data' property contains a string representing the exception, 
but we don't really like that. We'd like to propose that we use a new 
type of event, ErrorEvent, that looks like this:


  interface ErrorEvent : Event {
readonly attribute DOMString message;
readonly attribute DOMString filename;
readonly attribute unsigned long lineno;
  }


How do you feel instead about using the same mechanism on Worker objects 
as we currently use on Window for error handling?


Specifically, window.onerror is called as a function with three arguments 
when an error occurs. I'm suggesting that when a worker has an unhandled 
exception, we fire Worker.onerror outside the worker, again with three 
arguments (message, script url, line number). If the function return 
false, then the error reporting is quenched; otherwise, it is reported in 
the warning console.



I talked with Ben about this. We don't really feel strongly either way, 
so changing it is fine. That said, we already have the other behavior 
implemented so unless anyone feels strongly I suggest we keep it. I do 
agree there would be more consistency with window.onerror if we went the 
other way, but there would be less consistency with the other Worker.on*.


In any case, I do think that the bubbling mechanism should remain. 
I.e. that if the main window creates worker A, which creates a child 
worker B, and an error happens in B, then the following should happen:


1. A should be first given a chance to handle the error using B.onerror
2. If A doesn't handle the error the error is forwarded to the main
   window by calling A.onerror
3. If the main window doesn't handle the error, the error gets reported
   to any developer-error-console mechanism that the UA has (if any).

/ Jonas


Re: [whatwg] Preventing nested click() calls

2008-12-16 Thread Ian Hickson
On Mon, 10 Mar 2008, Antti Koivisto wrote:
 
 WebKit, Firefox and IE all implement a protection mechanism against re- 
 entering click() on the same element:
 
 input type=checkbox onclick=this.click()
 
 WebKit (and based on testing Firefox) make click() a no-op when invoked 
 as a result of a click event generated by calling click() on the same 
 element. For IE this seems to be true even for user generated click 
 events.

On Fri, 14 Mar 2008, Erik Arvidsson wrote:

 To me it just seems wrong to prevent this.  This is in theory no 
 different than a recursive call and just like recursion it can end up in 
 an infinite loop.  Having a limit seems OK since most JavaScript engines 
 already have a limit on the size of the call stack.

On Fri, 14 Mar 2008, Antti Koivisto wrote:

 In practice all browsers already treat click() as a special case. 
 Removing the nesting protection completely (and relying on js stack 
 limits) would break web sites so it is not an option. The only question 
 is whether the limit should be 1 or some other number. Matching the 
 existing implementations and disallowing nesting seems like a right 
 thing to do here.

On Fri, 14 Mar 2008, Geoffrey Garen wrote:
 
 You're right, it is no different *in theory*. It is, however, different 
 in practice. If we allow click() to re-enter itself, popular websites 
 stop working.

On Mon, 17 Mar 2008, Antti Koivisto wrote:

 Hixie asked for a concrete example of page that breaks if click() limit 
 is removed so here is one:
 
 1. Go to http://forums.whirlpool.net.au/
 2. Under Whirlpool (righthand side) go to 'Feedback Forum'
 3. Click on any Forum
 4. Click reply to this post (righthand) side
 5. Login (you need to create an account)
 6. Click 'Show quoted' box
 
 Without click() protection the last step hangs the browser (at least 
 until javascript time limit kicks in). Script is sufficiently complex 
 and slow to execute that it won't hit javascript stack limit. I tried 
 having a minimum nesting limit that passes Acid3 (10 iterations) and 
 that too produces a noticeable ~1s pause. On mobile class hardware that 
 would be a complete hang.

I've added the reentrancy block to HTML5.

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


Re: [whatwg] Should enter be mapped to click?

2008-12-16 Thread Ian Hickson
On Tue, 15 Jul 2008, Anne van Kesteren wrote:
 On Tue, 15 Jul 2008 09:50:25 +0200, Ian Hickson i...@hixie.ch wrote:
  On Mon, 14 Jul 2008, Aaron Leventhal wrote:
   
   Now that tabindex can be used on any element to make it focusable, it
   makes sense that it should be possible to trigger a click on those
   elements with the keyboard.
   
   Opera maps Enter to click. As far as I know, other browsers only do that
   for a few elements likea.
   
   What do people think? Should it be spec'd?
  
  3.4.1.7. Interactive content, paragraph 3:
  
  | When activation is performed via some method other than clicking the
  | pointing device, the default action of the event that triggers the
  | activation must, instead of being activating the element directly, be to
  | fire a click event on the same element.
 
 Last I checked that doesn't say each focusable element actually gets
 activation behavior as well. Here's an example:
 
   div tabindex=0 onclick=alert(0)TEST/div
 
 The specification states that only certain elements are interactive 
 content, not everything that's focusable.

Fixed.

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