[whatwg] fyi: Flash in JavaScript and SVG
Now, this is interesting. A bit of a dancing bear (i.e. not quite as good as Gnash) ... but he's achieved Flash on the iPhone to some degree! Code: http://github.com/tobeytailor/gordon/ Demos: http://paulirish.com/work/gordon/demos/ iPhone screenshot: http://twitpic.com/xxmi2 Browser support matrix: http://wiki.github.com/tobeytailor/gordon/browser-support-table Supported SWF tags: http://wiki.github.com/tobeytailor/gordon/swf-tag-support-table The author: http://www.xing.com/profile/Tobias_Schneider14 HTML5. Is there anything it can't do? - d.
[whatwg] Removing the FN magic in the vCard microdata vocabulary (Was: Microdata feedback)
On Thu, 21 Jan 2010, Philip Jägenstedt wrote: On Mon, 18 Jan 2010 16:24:46 +0100, Jeremy Keith jer...@adactio.com wrote: Hixie wrote: Finally on vCard, the final part of the extraction algorithm goes to great trouble to guess what is the family name and what is the given name. This guess will be broken for transliterated east Asian names (CJKV that I know of, maybe others too). Just saying. Also, why is it important to explicitly add N: for organizations? This is intended to be compatible with Microformats vCard, which has these weird rules. If you think we should remove them, please at least first speak to Tantek and see why he thinks. The fn optimisation pattern isn't intended to catch 100% of cases, just the situation Firstname Lastname or Firstname Middlename Lastname. So if you just use fn (formatted name) and don't use n (name), the name will be extracted/guessed using the optimisation pattern. In cases where the pattern doesn't work (e.g. Anne van Kesteren, or east Asian names) you can still explicitly specify the family name and given name, over-riding the fn optimisation pattern. If you do this, you need to explicitly state this is the name (n) as well as the formatted name (fn). This is going to break badly whenever a template uses vCard microdata and its author either doesn't know the family name and given name (because the data was never collected) or doesn't even consider that the vcard conversion does this funny guesswork. If a social network site or similar does this, then Anne van Kesteren and Zhang Min (fictional name) will have their names messed up with no way of fixing it. At least I haven't seen a site which asks users to both fill in their full name and each component, which is what you need to get this right. Similarly, for organisations, you don't have to explicitly set n (name) if you apply both fn (formatted name) and org (organisation name) to a string. This time, the optimisation pattern assumes that the fn is the name of the organisation. Technically, the n property is *always* required but if you use either of those two optimisation patterns, the n is inferred from fn. If this is just a technical problem with some software requiring N to be present, would it be OK to just output an empty N like for organizations? That's a good question... As I mentioned above, the rule is here to be compatible with Microformats. I'd be happy to remove it, but I'd like confirmation from the Microformats community that it's ok for us to diverge in this way from their vocabulary, and to find out if they have any experience regarding how much of a problem generating a blank N in the output when it's missing would be. Tantek, Jeremy, any opinions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] history.back()
On 1/29/10 3:32 AM, Ian Hickson wrote:
On Wed, 27 Jan 2010, Darin Fisher wrote:
I think that location.hash = 'a' should synchronously add #a to the
session history, or at least it should appear to the web page that it
was added synchronously.
[...]
That said, I think it would be good for location.hash = 'a' to interrupt
the history.back() request. The net result being that #a is appended
to session history, and the history.back() request is discarded.
[...]
I'm trying to treat history,{back,forward,go} as a UI command to the
navigator. Synthesize the user clicking on the corresponding
back/forward buttons. UI actions typically do not get dispatched during
JS execution (ignoring window.showModalDialog of course).
[...]
I agree that we should not change the location without traversing
history.
I'm arguing for making history.{back,forward,go} start out by
dispatching a task to then run the history traversal algorithm. So,
history.back() would never change the location synchronously.
I've tried to spec this. There is a high risk of compatibility issues, so
I would very much welcome feedback from implementors who try to implement
this.
The main goal of the change here is to make it possible to implement this
(if not completely sanely, but it's the Web, there's only so much I can
do) in a situation with each browsing context having its own process, as
seen to some extent in IE and Chrome, and as is being examined by other
browser vendors also.
So why sync history isn't possible in IE or Chrome?
I have seen some arguments why it is perhaps hard to implement, but
not possible at all?
While I was at it I made 'hashchange' and 'popstate' fire completely
async, and gave 'hashchange' context information to get around the problem
with it firing async (where it could e.g. fire twice for the same URL,
because the navigations get processed before it fires).
On Thu, 28 Jan 2010, Olli Pettay wrote:
On 1/28/10 7:15 AM, Darin Fisher wrote:
That said, I think it would be good for location.hash = 'a' to
interrupt the history.back() request. The net result being that #a
is appended to session history, and the history.back() request is
discarded.
Really? What if iframe has been navigated lately and something calls
history.back() (to load previous page in iframe), but right after that
top level page calls location.hash = foo;
Per spec now, any code along the lines of:
history.back();
location.hash = foo;
...will cause the back() to be a no-op. This is definitely incompatible
with legacy implementations; the question is whether there are pages
depending on it.
How should UA handle this case? User presses back (which hopefully
does pretty much the same as history.back()) but web page has some
loop like script which sets location.hash all the time.
Depending on the script state, back might not succeed?
Or does location.hash = foo; not clear the history tasks if
back()/forward() was caused by the UA/user.
I know there is When the user navigates through a browsing context,
e.g. using a browser's back and forward buttons, the user agent must
traverse the history by a delta equivalent to the action specified by
the user. but that doesn't quite clarify the situation, I think.
If we can't do this asynchronously, it's going to really suck for
multiprocess UAs,
Depends for example on whether UA wants to put different domains in
same tab to different processes. And even if it does do, synchronous
back()/forward() should be possible. Maybe just not as easy.
So I'm not sure that suck for multiprocess UAs is a really good
argument here.
so I think it's worth trying to find a solution here,
even if there is a back-compat risk. In practice I don't think the risk
is as high as it could be, because interop is pretty poor in this area
already; in particular, Chrome does things that are quite drastic when
given code like the above, and Chrome developers aren't aware of having
received bugs about it.
Again, please send feedback on this. The diff is:
http://html5.org/tools/web-apps-tracker?from=4631to=4632
Uh, changing hashchange again to async. We must stop changing that all
the time. Though in this case I like the change. I never really
understood the sync hashchange, or the reasoning why it was changed to
be sync.
So history.back(); history.back(); would queue 2 tasks?
And first one document is loaded (maybe from bfcache), and it could
synchronously do something like dispatch pageshow or whatever which
could do things like alert() and then second document was loaded at
somepoint. Kind of strange way to handle history.back().
-Olli
Re: [whatwg] api for fullscreen()
On 1/28/10 10:41 PM, Kit Grose wrote: True, but surely saying any element opens the door to full-screening inline text elements (e.gspan elements). I don't see why this is a problem, offhand. I suppose the native style being position: fixed would put those elements in a block formatting context anyway More precisely would make them block-level in CSS terms. A block formatting context is something different. but what implications might that have for things like table cells/table rows being made full-screen? For table cells, none whatsoever. For table rows, that's a good question. If one just makes them position:fixed, that would basically mean you create an anonymous table inside the row (in particular, you redo column balancing on the row's cells while ignoring all the other rows of the table). Is that the desired behavior? If not, what is? There may be no good solutions here. The other interesting thing with table rows is what should happen with cells spanning into the row or out of it. With the position:fixed approach the former would not appear and the latter would just be visible in their entirety. Again, it's not clear to me whether there's a good behavior here. -Boris
Re: [whatwg] api for fullscreen()
On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote: On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com wrote: We have been discussing a more general fullscreen API that lets you take the page fullscreen (perhaps with the ability to focus on a single element), as Maciej mentions. We have not decided on a final form for this API, nor have we resolved whether it's possible to do some nice transition between the two modes. We have talked at some length about the security issues. Input on what people would like from this API is welcome, as are ideas on how the transitions should work. 1) Should be convenient for authors to make any element in a page display fullscreen 2) Should support in-page activation UI for discoverability I agree with Boris that we should leave this up to the page author. 3) Should support changing the layout of the element when you enter/exit fullscreen mode. For example, authors probably want some controls to be fixed size while other content fills the screen. 4) Should accommodate potential UA security concerns, e.g. by allowing the transition to fullscreen mode to happen asynchronously after the user has confirmed permission Agreed. New API for all elements: void enterFullscreen(optional boolean enableKeys); void exitFullscreen(); boolean attribute supportsFullscreen; boolean attribute displayingFullscreen; beginfullscreen and endfullscreen events Those seem reasonable for a proposal where a single element is taken fullscreen. While an element is fullscreen, the UA imposes CSS style position:fixed; left:0; top:0; right:0; bottom:0 on the element and aligns the viewport of its DOM window with the screen. Only the element and its children are rendered, as a single CSS stacking context. So this makes it a very element-focused API (as does the enterFullscreen() method on Element that you propose above). Another approach would be to leave it entirely up to the page author to style their page differently when in fullscreen, and not have the API force them to focus on one element. Then the API would probably be on the Window object, and the UA would simply transition the view to a fullscreen presentation. There could be a pseudo-class to the body, or a way to use media queries to allow the author can apply different styles for fullscreen. In this scenario the author is not forced to nest all their fullscreen content under one element, and can continue to show the rest of the page content (maybe dimmed out by a semi-transparent overlay div) in the background. The disadvantage of this approach is that it makes it much harder for the UA to do any kind of automatic transitions between the two presentations (though it's not clear to me that nice automatic transitions will be possible with the element-based API either). Simon
[whatwg] Fixing the submit event by exposing submitter and data set
When a user binds to a form's submit event, it's almost always for one of three
purposes:
1. To prevent submission, if the page or form is in an unsubmittable state
2. To handle submission in a non-default way (submit it asynchronously or use
it locally)
3. To add to the data in the form before it's submitted
The result is that every major JavaScript framework has functionality to
extract the data from a form. [This page compares][1] the behavior of the most
popular ones. *None* of the framework results match any of the others, except
for jQuery and jQuery Form, and *none* of the framework results match my UA's
results (WebKit r53990). Scripts handling the submit event can't get at the
submitter, which makes it impossible to know its name, value, and mouse
coordinates (in the case of image inputs) without binding to click on every
button in the form and keeping track of which one fired in the same event loop
as submit. This is how forms are handled today.
JavaScript authors shouldn't be in the game of implementing the HTML API. I
propose that the [form submission algorithm][2] be rearranged slightly so that
the form data set is constructed before the submit event fires, and the data
set and submitter are exposed as properties on the submit event.
The data set might look like this:
[
{
name: someName,
value: someValue,
node: input
},
{
name: otherName,
value: otherValue,
node: input
},
...
]
...where `name` and `value` are the name and value to be submitted, and `node`
is a reference to the element that caused that pair to be created.
If I want to submit additional data describing some state on the page, right
now I have to create an input, set its type to hidden, set its name and value,
append it to the form, and, if I don't plan to target the form at its own
browsing context, wait for the submit to run, and remove it from the form. With
this new model, sending extra data could be as simple as
formData.push({ name: someAdditionalName, value: someAdditionalValue });
In this case, `node` would be undefined. It's also conceivable that objects
could be deleted from the data array (maybe in the case that an input only has
relevance to the script handling a form and not to its action), and that the
names and values could be writeable without mutating the name or value of the
associated input (I don't have use case for this last one). The implementation
would have to handle inputs being added, removed, or modified during the submit
event. I think that the cleanest way to deal with this would be to update the
data object synchronously to reflect those changes, so that behavior remains
backwards compatible. There may be a better way, or my whole implementation
could be garbage.
What do you think?
[1]: http://jquery.malsup.com/form/comp/
[2]: http://www.w3.org/TR/html5/forms.html#form-submission-algorithm
smime.p7s
Description: S/MIME cryptographic signature
Re: [whatwg] api for fullscreen()
While an element is fullscreen, the UA imposes CSS style position:fixed; left:0; top:0; right:0; bottom:0 on the element and aligns the viewport of its DOM window with the screen. Only the element and its children are rendered, as a single CSS stacking context. So this makes it a very element-focused API (as does the enterFullscreen() method on Element that you propose above). Another approach would be to leave it entirely up to the page author to style their page differently when in fullscreen, and not have the API force them to focus on one element. Then the API would probably be on the Window object, and the UA would simply transition the view to a fullscreen presentation. There could be a pseudo-class to the body, or a way to use media queries to allow the author can apply different styles for fullscreen. In this scenario the author is not forced to nest all their fullscreen content under one element, and can continue to show the rest of the page content (maybe dimmed out by a semi-transparent overlay div) in the background. Well, as an author, you can always choose to make the body element go fullscreen, wouldn't you? So you can have both: - use a single div with all it's content - use a video element - or use the body, so that the whole page goes fullscreen. And if there is a pseudo-class on this element, you can always style the content accordingly. Best regards, Frank Hellenkamp -- frank hellenkamp | interface designer solmsstraße 7 | 10961 berlin +49.30.49 78 20 70 | tel +49.173.70 55 781 | mbl +49.3212.100 35 22 | fax jo...@depagecms.net http://www.depagecms.net http://immerdasgleiche.de http://everydayisexactlythesame.net/ signature.asc Description: OpenPGP digital signature
Re: [whatwg] figureimg* caption
I've changed figure and details again, hopefully for the last time. They now have unique elements for their legends: figure figcaption.../figcaption ... /figure details summary.../summary ... /details On Mon, 30 Nov 2009, Philip Jägenstedt wrote: As currently speced, the proper usage of figure is: figure ddimg src=bunny.jpg alt=A Bunny/dd dtThe Cutest Animal/dt /figure Apart from all that has been said about legacy parsing, leaking style in IE, etc I would (perhaps not be the first to) add: 1. It seems quite easy to confuse or mistype dd/dt. Without guessing how often authors will get it wrong, I think everyone agrees that (all else equal) a syntax which is harder to confuse/mistype is better. 2. Only the caption needs to be marked up, the content is implicitly everything else. While some content may need a wrapping element for styling, e.g. img usually does not. 3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone else's.) Hopefully this is now resolved. The main difficulty with coming up with something better seems to have been finding a name for an element which isn't already taken. If that's the only issue, why not just take some inspiration from time pubdate and use an attribute instead? figure img src=bunny.jpg alt=A Bunny p captionThe Cutest Animal/p /figure At least to me, it looks clean enough and there are no serious parsing issues (just use document.createElement(figure) for IE). The caption is easy to style with figure *[caption] or any number of easy workarounds for browsers that don't support CSS attribute selectors (IE6?). I haven't been following the discussions on figure closely, so if this has already been discussed and rejected please link me in the right direction. I considered this, but it makes the processing much more complicated and fiddly everywhere, so I don't think it's a good design. On Mon, 30 Nov 2009, Tab Atkins Jr. wrote: The only thing you have to answer is what to do if there are multiple @caption elements in the figure. I suggest taking either the first or last; the exact choice is pretty much arbitrary. That's not the only problem... you also have to worry about the attribute being used on elements that can't really be moved around easily, or that are part of content; you have to consider what happens when the caption gets wrapped, there's the danger of authors misunderstanding how it works (since it's pretty unique as a mechanism), etc. e.g., consider: details Copying from volume A to X. Status: span legend54 files copied/span of 102 total. 23 minutes remaining. /details How would it render? What if you want to put paragraphs around each of those lines? On Mon, 30 Nov 2009, Nils Dagsson Moskopp wrote: Tab Atkins Jr. jackalm...@gmail.com schrieb am Mon, 30 Nov 2009 12:50:42 -0600: Note: I would style it with figure [caption] instead, to ensure you don't accidentally grab misplaced captions. I would like to style captions on top differently from captions underneath. What now ? Where the caption goes is a styling issue, so I don't think that's a problem really. Just style it when you position it. If you mean you want to apply meaning to where the element is in the DOM, then as Tab says, you can use selectors: On Mon, 30 Nov 2009, Tab Atkins Jr. wrote: figure [caption]:first-child or figure [caption]:last-child On Mon, 30 Nov 2009, Nikita Popov wrote: But still, why do we need the figure-wrapper? It would be cleaner syntax, in my eyes, if you could easily specify an element that is related as a caption to another element. Could look like this: img src=bunny.jpg alt=A Bunny id=bunny p caption=bunnyThe Cutest Animal/p or img src=bunny.jpg alt=A Bunny id=bunny p for=bunnyThe Cutest Animal/p This leads to very confusing markup. Just as we found h1ph2p to be confusing and are moving towards sectionh1psectionh2p /section/section, I think we should avoid using inter-element references where possible. Or used in the code-context: code id=mygreatscriptecho 0;/code strong for=mygreatscriptDoes nothing, but it's still cool!/strong I know, I know, for is used for labelled form elements, but I think, that is expresses very well the relation between content and caption. Furthermore, any related content could be marked up this way. I think it is _theoretically_ sound, but it is very hard to use in practice. For example, there is this strange hgoup-tag, that's used fore grouping title and subtitle: hgroup h1Somethind great happened/h1 h2Now some subtitle in a newspaper article.../h2 /hgroup If I wanted to place an image between title and subtitle of the article, it would look something like this: hgroup h1Somethind great happened/h1 figure ddimg src=Aphotoofit //dd dtDescr. of img./dt /figure h2Now some subtitle in a
Re: [whatwg] api for fullscreen()
On Sat, Jan 30, 2010 at 5:49 AM, Simon Fraser s...@me.com wrote:
On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote:
1) Should be convenient for authors to make any element in a page display
fullscreen
2) Should support in-page activation UI for discoverability
I agree with Boris that we should leave this up to the page author.
Leaving it up to the page author was what I meant by in-page UI, I just
didn't phrase it well.
While an element is fullscreen, the UA imposes CSS style position:fixed;
left:0; top:0; right:0; bottom:0 on the element and aligns the viewport of
its DOM window with the screen. Only the element and its children are
rendered, as a single CSS stacking context.
So this makes it a very element-focused API (as does the enterFullscreen()
method on Element that you propose above).
Another approach would be to leave it entirely up to the page author to
style their page differently when in fullscreen, and not have the API force
them to focus on one element. Then the API would probably be on the Window
object, and the UA would simply transition the view to a fullscreen
presentation. There could be a pseudo-class to the body, or a way to use
media queries to allow the author can apply different styles for fullscreen.
In this scenario the author is not forced to nest all their fullscreen
content under one element, and can continue to show the rest of the page
content (maybe dimmed out by a semi-transparent overlay div) in the
background.
The latter is easy to do with my proposed API too: just give the fullscreen
element a non-opaque background.
The disadvantage of this approach is that it makes it much harder for the UA
to do any kind of automatic transitions between the two presentations
(though it's not clear to me that nice automatic transitions will be
possible with the element-based API either).
I suggested an approach for transitions above: apply style changes, render
the element at the size of the screen, and then zoom that image out from the
element's old position to the screen size. Because video self-letterboxes,
you can make this always look good for video even if the screen has a
different aspect ratio to the original size of the video element.
There is an additional issue I just thought of: with either approach, you'll
normally want to hide the viewport scrollbar. You could just say that the UA
hides the viewport scrollbar while the viewport is in fullscreen mode. Or
you could use a pseudoclass to set overflow:hidden on the root element,
which would let the author override it, or make the user do that manually.
So how about a Window API with an optional element component:
void enterFullscreen(optional DOMElement element, optional boolean
enableKeys);
void exitFullscreen();
boolean attribute supportsFullscreen;
boolean attribute displayingFullscreen;
beginfullscreen and endfullscreen events
Where beginfullscreen and endfullscreen are targeted at the element if
one was provided, or else at the window, and bubble. While a window is
fullscreen, the root element and the designated fullscreen element, if any,
are given a pseudoclass fullscreen. Then you can have some default rules
in the UA style sheet:
*:root:fullscreen { overflow:hidden; }
*:not(:root):fullscreen { position:fixed; left:0; top:0; bottom:0; right:0;
}
Rob
--
He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all. [Isaiah
53:5-6]
