Re: [whatwg] VIDEO tag height/width best fit
Video is automatically scaled to fit inside its box while maintaining the correct aspect ratio. Philip On Mon, 2008-08-04 at 00:19 -0400, Biju [EMAIL PROTECTED] wrote: I apologize if I did not understood http://www.whatwg.org/specs/web-apps/current-work/#video I see a situation where we want to specify the height and width of the BOX in which a video need to be displayed. And while writing HTML code we dont know the height/width of the video. But when playing we want the video to be displayed with maximum size which can fit in the BOX without loosing the aspect ratio. After reading the video tag specification I dont see a way to achieve this with out javascript code. We should have one more attribute to tell how to fit the image/video == fit attribute values === * center - if it is small keep at center * stretch - stretch/skew height and width to fit * stretch-height - stretch/skew height only to fit, adjust width to maintain aspect ratio. * stretch-width - stretch/skew width only to fit, adjust height to maintain aspect ratio. * stretch-best- stretch/skew height or width to maximum so that other will fit in and maintain aspect ratio. May be we can also have a tile option This problem also exist for img tag. -- Philip Jägenstedt Opera Software
[whatwg] Images and alternative text
On Fri, 18 Apr 2008, Bill Mason wrote: The example was a case of a hacker who replaces the Google logo on google.com with an image only containing the text WE HACKED YOUR SERVERS. We assume the hacker cares enough about accessibility to set the alt attribute to the same text. The new image would appear to fall into the phrase or paragraph with an alternative graphical representation requirement. The spec's current language that the image is something [that] can be more clearly stated in graphical form something doesn't fit well because this hypothetical image is not 'more clear' -- it's equivalent. Added a section for this case. On Fri, 18 Apr 2008, Philip Taylor wrote: I believe the company logo case is also unclear in the spec. See e.g. http://www.google.com/ (when it's not a special day) - the image is simply the word Google (as a page heading, so it should probably be in h1), so common sense says it should have alt=Google. The spec phrase Icons: a short phrase or label with an alternative graphical representation sounds like it might apply here, but none of the cases in that section seems to work: in particular, I don't think the logo is being used to represent the entity would apply, because the purpose of the image is not to represent the entity (as it would be in e.g. a list of search engines that shows small images of all their logos so you can choose your favourite), and instead its purpose is to tell users what site they are on (and to make it look prettier). It should be made clearer whether the existing case does or does not apply. If it does not apply, it should be made clear what alt text to use instead. I've added text to clarify this case. What should happen for 'tracker' images? (i.e. img src=http://evil.google.com/user-track.php?site=97519340; width=1 height=1 alt=???) Added a section. [...] some versions of Google (depending on cookies, IP address, etc) implement the Google logo as four separate images [...] Added a section. And as a more general point, the spec provides a list of cases for using img (and how to use alt for those cases), but this list will never be complete (especially since the case matches are all subjective and open to interpretation in multiple ways), so there needs to be a default case statement for images where the author doesn't think any of the specific requirements applies. I'd like to try making it comprehensive first. Am I missing any other cases? On Sat, 19 Apr 2008, Simon Pieters wrote: [counter images] Moreover, such images often use width=0 height=0, but that's invalid per HTML5, which seems a bit unhelpful. Those images aren't representing images, so they seem invalid to me. If we want to support this case it seems like there have got to be better ways to do it. [slicing] For instance it would be reasonable to use two images -- a filled star and an unfilled star -- to represent a rating of something: pRating: img src=1img src=1img src=1img src=0img src=0/p You'd want the text version to be: Rating: 3/5 Hence: pRating: img src=1 alt=3/5img src=1 altimg src=1 altimg src=0 altimg src=0 alt/p Added an example like this to the spec. On Sat, 19 Apr 2008, Edward O'Connor wrote: HTML5 provides the meter element for this use case. pRating: meter3/5/meter/p I've used meter in the example, to hint at this. On Sun, 20 Apr 2008, Shannon wrote: What about this as a possible solution? img src=part1.png altgroup=rating img src=part2.png altgroup=rating img src=part3.png altgroup=rating altgroup id=rating value=3/5 I don't think this would raise any serious implementation issues as the logic is quite simple; If all elements in an altgroup are unavailable then display the value of the altgroup tag. The alt attribute would then be optional where altgroup is defined but required in all other cases. This seems over-engineered for such a simple problem. On Mon, 21 Apr 2008, Shannon wrote: Yes this proposal requires a new tag and attribute but that is a lot less disruptive than giving designers an easy way to opt out of accessibility (while still claiming compliance). I'd like to believe that designers would do the right thing without being told but I know for a fact most of them don't. The alt requirement for w3c validation is what got me using them in the first place so I know it's having some effect. The spec doesn't allow them to claim compliance without being accessible here. On Mon, 21 Apr 2008, Shannon wrote: Not the same thing at all. There is no direct association between the elements so there is no way a validator or browser would know the difference between a missing/empty alt and an optional one - thus making ALL use of alt optional as far as formal validation is concerned. Well, similarly there's no way for the validator to know if the alt= attribute is allowed to be empty, or is
Re: [whatwg] VIDEO tag height/width best fit
On Mon, 4 Aug 2008, Biju [EMAIL PROTECTED] wrote: I apologize if I did not understood http://www.whatwg.org/specs/web-apps/current-work/#video I see a situation where we want to specify the height and width of the BOX in which a video need to be displayed. And while writing HTML code we dont know the height/width of the video. But when playing we want the video to be displayed with maximum size which can fit in the BOX without loosing the aspect ratio. It's automatically like this. # Video content should be rendered inside the element's playback area such # that the video content is shown centered in the playback area at the # largest possible size that fits completely within it, with the video # content's adjusted aspect ratio being preserved. -- http://www.whatwg.org/specs/web-apps/current-work/#video Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for a link attribute to replace a href
Ian Hickson wrote: Every now and then, the issue of a global href= attribute for all elements comes up. There are many valid use cases for this, like being able to make all cells in a table row act like a link, or making a banner ad act like a single block of a link. Unfortunately, I've been told over and over by implementers that a global href= is a bad idea, and at the end of the day, the implementors are the ones who have the final say, so that's just a non-starter. Which implementations have you heard this from? As far as mozilla goes we would have no technical problems implementing this. The problems that I can see are of a more 'social' type. I.e. how to behave when two links are nested, or when a button is nested inside a link. Or how the event model interacts with the navigation action. All these problems exist already, but might become more common if it was easier to sprinkle 'href' attributes throughout the DOM. / Jonas
Re: [whatwg] HTML 5 : Misconceptions Documented
I'm a little surprised at the lack of response here, so I'm replying
to myself here, just to keep this issue active.
I did a little more research and found that the misconception is more
common that I thought: DOM objects that have indexed properties are
often mistaken for arrays. This is the misconception that I found
documented in HTML5.
The following documents discuss DOM Collections using the term Array:
http://www.quirksmode.org/dom/w3c_core.html#t60
http://www.quirksmode.org/dom/tests/attributesArray.html
http://www.quirksmode.org/dom/tests/stylesheets.html
http://ajaxian.com/archives/preloading-images-with-jquery#javascript-1
http://jennifermadden.com/javascript/arraySimple.html
http://httpunit.sourceforge.net/doc/javascript-support.html
Ian had politely asked me to post this information to the list.
Calling an HTMLCollection an array will mislead developers who don't
know the difference. It might also lead a reader to believe that the
author of the HTML specification deliberately used the word 'array'
and that elements is an array (not an HTMLCollection).
It seems that the only benefit in calling an HTMLCollection an array
is that 'array' is shorter to type.
Typing HTMLCollection is longer than typing array but it is misleading.
But that still leaves the other two issues. The first is the worst, I
think, because it relies on deprecated behavior and isn't very good
practice.
Garrett
On Tue, Jul 29, 2008 at 11:33 PM, Garrett Smith [EMAIL PROTECTED] wrote:
I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of programming by coincidence.
These reflect very poorly on html5.
The errors can be found on the link:
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
Doc Bugs:
1) Treating a a form element as an HTMLCollection.
2) The use of - with - to augment the scope chain is not necessary.
3) Calling the elements HTMLCollection an array
(1) The definition of HTMLFormElement does not have a specialized [[Get]]
for element names (nor should there be, as this is known to be
problematic). The example in the documetation depends on such behavior.
(2) - with - augments the scope chain with the object. This is completely
unnecessary here and will create problems if, for example, there is an
element named watch. It is a bad practice and I see this influence in the
popular libraries.
(3) There is no specification for a special [[Get]] for the elements
HTMLCollection as a shortcut to namedItem, either (though this would not
seem to be a problem, and all implementations have supported this behavior
for quite a long time). I did notice that the elements collection is
mistakenly called an 'array'. This is a serious documentation mistake of
the worst kind: The spreading of misinformation. It will continue influence
the muddy knowledge that is so common among most developers who tend want
to call push et c directly on that NodeList object (see the
dojo.NodeList for details). The elements Collection should be called an
HTMLCollection and this should be changed immediately.
// WRONG
document.forms[0].qty,
The elements property is what the example should use:-
// RIGHT.
document.forms[0].elements.namedItem('qty');
document.forms[0].elements.qty; // Access via custom get
This avoids ambiguity when having a form that has an element named name,
for example. It becomes ambiguous as to whether the form.name refers to
the element or the form's name attribute. Problems could also arise with
action, length, toString, elements.
-
// (GS) Don't augment scope chain here.
with (document.forms[0]) {
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
if (qty.validity.valueMissing) {
// the quantity control is required but not filled in
} else if (qty.validity.typeMismatch) {
// the quantity control is filled in, but it is not a number
}
}
And further down:-
// (GS) Don't treat a form as a collection.
// Use the 'elements' colletion.
var myControl = document.forms[0].addr;
if (myControl.value == '[EMAIL PROTECTED]') {
myControl.setCustomValidity('You must enter your real address.');
}
-
Fixed:
var f = document.forms[0],
qv = f.elements.namedItem('qty').validity;
if (qv.valueMissing) {
// Value required but not filled in.
} else if (qv.typeMismatch) {
// Value filled in, but it is not a number.
}
}
var addErrInvalidMsg = 'You must enter your real address.';
var addr = document.forms[0].elements.namedItem('addr');
if (addr.value === '[EMAIL PROTECTED]') {
addr.setCustomValidity(addErrInvalidMsg);
}
Re: [whatwg] Proposal for a link attribute to replace a href
Jonas Sicking wrote: Ian Hickson wrote: Every now and then, the issue of a global href= attribute for all elements comes up. There are many valid use cases for this, like being able to make all cells in a table row act like a link, or making a banner ad act like a single block of a link. Unfortunately, I've been told over and over by implementers that a global href= is a bad idea, and at the end of the day, the implementors are the ones who have the final say, so that's just a non-starter. Which implementations have you heard this from? As far as mozilla goes we would have no technical problems implementing this. The problems that I can see are of a more 'social' type. I.e. how to behave when two links are nested, or when a button is nested inside a link. Or how the event model interacts with the navigation action. All these problems exist already, but might become more common if it was easier to sprinkle 'href' attributes throughout the DOM. Actually, I think I spoke a bit too broadly. Just adding support for the 'href' content attribute, and the ability to click and style those elements just like you can an a today should be easy, at least in gecko. This is modulo the issue of what happens with the elements that already have a 'href' attribute with a different meaning (i.e. other than making the element into a clickable link), such as base and link However if we want to add support for the long list of JS attributes that exist on a elements today on each and every HTML element I suspect that is going to get messier. Especially considering the collisions for base and link. What would myBaseElement.accessKey do? And is myDivElement.protocol really intuitive what it does? However these are problems that can be solved on a spec level IMHO. / Jonas
Re: [whatwg] Proposal for a link attribute to replace a href
On Mon, 04 Aug 2008 20:21:01 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: However if we want to add support for the long list of JS attributes that exist on a elements today on each and every HTML element I suspect that is going to get messier. Especially considering the collisions for base and link. What would myBaseElement.accessKey do? And is myDivElement.protocol really intuitive what it does? Also it would quite likely clash with existing content that expects that those attributes don't exist on e.g. divs. (Opera has had problems with some new DOM attributes in WF2 due to legacy.) -- Simon Pieters Opera Software
[whatwg] Aborting an in-progress database transaction
It seems like you need a way to abort an in-progress transaction. An easy way to do this would be to add an abort() method to SQLTransaction. Thoughts? - a
[whatwg] database transactions should be serialized
I think this has been covered in passing before, but I wanted to bring it up explicitly. Currently, the database API has an error code for the situation where you open a transaction for read, then try to write but the database is locked. I think that the spec should at least suggest, but perhaps require, implementors to serialize access to a single database to prevent this from happening. Without this, developers must wrap every single write attempt in error handling and retry if a lock error occurs. It seems likely that developers will forget to do this and it will be a significant pain point with the API. Applications will seem to work, but then mysteriously fail in production when users have multiple copies of the application open. Even if the developer adds retry logic, it is easy for a page to get starved by another page. Serializing access would prevent all these problems at the cost of read concurrency, which I think is OK for the first version of this API. A future version of the API could add the concept of read transactions which would allow concurrency, but would fail immediately when you try to write with them. - a
Re: [whatwg] canvas shadow compositing oddities
Philip Taylor wrote: On Sun, Jul 27, 2008 at 8:06 PM, Eric Butler [EMAIL PROTECTED] wrote: [...] However, following the spec's drawing model, there are a few operators that behave rather unexpectedly if the shadow color is left at its default value. For instance, since A in B always results in transparency if either A or B is fully transparent, source-in will always simply clear the clipping region to fully transparent no matter what the source and destination are. Oops - that does seem quite broken. (It's probably my fault - I didn't notice that problem when I was looking at how shadows should work... The need to be able to disable shadows explicitly seems clear. But I also believe that the spec should provide for a means to disable normal drawing and only draw shadows to increase the usefulness of shadows. As it stands, if you draw with shadows, you'll end up getting some of the shadows drawn on top of some of the actual shapes. But perhaps the developer wants to have all shadows behind all shapes for a particular set of shapes. The only way to accomplish that would be to create a second canvas, do all the drawing without shadows on that, then draw the canvas with its shadow back to the original, which seems cumbersome to use and is terribly inefficient. It would be simpler if the user could simply turn on only shadows, do the drawing once, then turn on only normal rendering and do the drawing again. You cannot simply set the fill/stroke style to transparent for the same reason that it doesn't quite work for shadows. So I believe that the spec should provide for the means to explicitly disable both shadows and normal drawing separately. To that end, perhaps there could be an attribute which indicated what the current state of the drawing model was: object only, shadow only, or objects and shadows, defaulting to drawing only objects. This would create more expected output for all composite operators, and would allow developers to do some more complex tricks with shadows. Oliver Hunt wrote: We could special case opacity 0, with 0,0 offset, and 0 blur radius as being a do not draw shadow flag perhaps? This wouldn't solve the problem of disabling normal drawing and doesn't seem like a very clean API to me. A more explicit attribute seems better in my opinion. While it is true that having shadows and objects always in the drawing model can be hacked around when all but certain uncommon composite operators are being used, it seems unclean to have to keep flipping the style back and forth to hack around things. Furthermore, it is extremely difficult if not impossible to achieve certain effects without the ability to modify the drawing model. So I believe such a means should be provided. -Eric Butler
Re: [whatwg] HTML 5 : Misconceptions Documented
On Wed, Jul 30, 2008 at 8:33 AM, Garrett Smith wrote:
(3) There is no specification for a special [[Get]] for the elements
HTMLCollection as a shortcut to namedItem, either (though this would not
seem to be a problem,
Actually, there is:
http://www.w3.org/TR/html5/dom.html#htmlcollection
and I believe the elements property of HTMLFormElement is actually
an HTMLFormControlsCollection:
http://www.w3.org/TR/html5/dom.html#htmlformcontrolscollection
and all implementations have supported this behavior for quite a long time).
Note that all implementations also supports the same behavior on
HTMLFormElement and HTMLDocument.
Otherwise, FWIW, I'm OK with what you're saying about the use of
with(...){...} (useless and generally considered bad practice) and
calling a collection array.
--
Thomas Broyer
Re: [whatwg] canvas shadow compositing oddities
On Aug 4, 2008, at 2:29 PM, Eric Butler wrote: Philip Taylor wrote: On Sun, Jul 27, 2008 at 8:06 PM, Eric Butler [EMAIL PROTECTED] wrote: [...] However, following the spec's drawing model, there are a few operators that behave rather unexpectedly if the shadow color is left at its default value. For instance, since A in B always results in transparency if either A or B is fully transparent, source-in will always simply clear the clipping region to fully transparent no matter what the source and destination are. Oops - that does seem quite broken. (It's probably my fault - I didn't notice that problem when I was looking at how shadows should work... The need to be able to disable shadows explicitly seems clear. But I also believe that the spec should provide for a means to disable normal drawing and only draw shadows to increase the usefulness of shadows. As it stands, if you draw with shadows, you'll end up getting some of the shadows drawn on top of some of the actual shapes. But perhaps the developer wants to have all shadows behind all shapes for a particular set of shapes. The only way to accomplish that would be to create a second canvas, do all the drawing without shadows on that, then draw the canvas with its shadow back to the original, which seems cumbersome to use and is terribly inefficient. I think that'll cause problems as well -- for example, let's say you had two overlapping paths that you wanted to draw a shadow behind. The two paths are both solid and are supposed to be rendered as a single shape to the user. If you drew them separately with shadows, as it stands now, the shadows would end up adding and would be denser in the overlap areas which isn't what the author would intend. I would suggest: - special case opacity 0, 0,0 offset, 0 blur radius as 'shadows off', as Oliver suggested to preserve current usage - if shadows aren't off, draw them normally -- one shadow per drawing operation - go the whole way and add beginLayer/endLayer, akin to CGContextBeginTransparencyLayer[WithRect]/EndTransparencyLayer. Could also call it pushGroup/popGroup. As a side benefit, this would provide a simple way to implement double-buffered rendering without needing to use two canvases. (http://developer.apple.com/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#/ /apple_ref/c/func/CGContextBeginTransparencyLayer) - Vlad
[whatwg] Nested lists?
Are there plans to natively support nested unordered lists in HTML 5? I'm referring here to something like this: Top level list item |-- Childless second level list item |-- Another childless second level list [+]- Collapsed second level list item with children [-]- Expanded second level list item with children ||-- Third level list item ||-- Another third level list item | [+]- Collapsed third level list item with children | [-]- Expanded third level list item with children |||-- Fourth level list item |||__ Another fourth level list item ||__ A final third level list item [+]- Another collapsed second level list item |__ A final second level list item This is already possible through CSS, but these kinds of nested lists are more organizational than presentational and could benefit from native support with their own kind of unordered list element. The markup for the above list could be something like this: nl li id=fooTop level list item/li lg parent=foo liChildless second level list item/li liAnother childless second level list item/li li id=barCollapsed second level list item with children/li lg parent=bar !-- Child list items here -- /lg li id=threeExpanded second level list item with children/li lg parent=three liThird level list item/li liAnother third level list item/li li id=fourCollapsed third level list item/li lg parent=bar !-- Child list items here -- /lg li id=fiveExpanded third level list item with children/li lg parent=bar liFourth level list item/li liAnother fourth level list item/li /lg liA final third level list item/li /lg li id=booAnother collapsed second level list item/li lg parent=boo !-- Child list items here -- /lg liA final second level list item/li /lg /nl Or you could define the list groups separately, at the beginning or end of the nl.
[whatwg] Nested lists
Are there plans to natively support nested unordered lists in HTML 5? I'm referring here to something like this: Top level list item |-- Childless second level list item |-- Another childless second level list [+]- Collapsed second level list item with children [-]- Expanded second level list item with children ||-- Third level list item ||-- Another third level list item | [+]- Collapsed third level list item with children | [-]- Expanded third level list item with children |||-- Fourth level list item |||__ Another fourth level list item ||__ A final third level list item [+]- Another collapsed second level list item |__ A final second level list item This is already possible through CSS, but these kinds of nested lists are more organizational than presentational and could benefit from native support with their own kind of unordered list element. The markup for the above list could be something like this: nl li id=fooTop level list item/li lg parent=foo liChildless second level list item/li liAnother childless second level list item/li li id=barCollapsed second level list item with children/li lg parent=bar !-- Child list items here -- /lg li id=threeExpanded second level list item with children/li lg parent=three liThird level list item/li liAnother third level list item/li li id=fourCollapsed third level list item/li lg parent=bar !-- Child list items here -- /lg li id=fiveExpanded third level list item with children/li lg parent=bar liFourth level list item/li liAnother fourth level list item/li /lg liA final third level list item/li /lg li id=booAnother collapsed second level list item/li lg parent=boo !-- Child list items here -- /lg liA final second level list item/li /lg /nl Or you could define the list groups separately, at the beginning or end of the nl.N
[whatwg] audio controls
Currently the spec doesn't say anything about the rendering of the audio element. Webkit makes audio without controls display:none by default, which seems reasonable, but it would be nice if spec recommended this behaviour. When controls is added, the element needs to be visible, so it will need an intrinsic size. Since the spec specifies the intrinsic size for video, shouldn't it do so for audio as well? 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]
Re: [whatwg] VIDEO tag height/width best fit
I dont get this effect in new firefox see https://bugzilla.mozilla.org/attachment.cgi?id=332287 So can I am assuming it is a firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=449142 On Mon, Aug 4, 2008 at 6:58 AM, Ian Hickson [EMAIL PROTECTED] wrote: On Mon, 4 Aug 2008, Biju [EMAIL PROTECTED] wrote: It's automatically like this. # Video content should be rendered inside the element's playback area such # that the video content is shown centered in the playback area at the # largest possible size that fits completely within it, with the video # content's adjusted aspect ratio being preserved. -- http://www.whatwg.org/specs/web-apps/current-work/#video
Re: [whatwg] audio controls
On Tue, 5 Aug 2008, Robert O'Callahan wrote: Currently the spec doesn't say anything about the rendering of the audio element. Webkit makes audio without controls display:none by default, which seems reasonable, but it would be nice if spec recommended this behaviour. When controls is added, the element needs to be visible, so it will need an intrinsic size. Since the spec specifies the intrinsic size for video, shouldn't it do so for audio as well? Agreed with all the above. I was hoping to put details about the intrinsic size of the controls of audio and video elements into the rendering section, based on what browsers implemented. :-) I don't have any opinion either way about what it should be. Looks like for video, the trend is to use overlaying controls (obviously that won't work for audio). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Nested lists?
On Mon, 4 Aug 2008, noclip wrote: Are there plans to natively support nested unordered lists in HTML 5? I'm referring here to something like this: Top level list item |-- Childless second level list item |-- Another childless second level list [+]- Collapsed second level list item with children [-]- Expanded second level list item with children ||-- Third level list item ||-- Another third level list item | [+]- Collapsed third level list item with children | [-]- Expanded third level list item with children |||-- Fourth level list item |||__ Another fourth level list item ||__ A final third level list item [+]- Another collapsed second level list item |__ A final second level list item You can do the above today using the datagrid element and the ul element, as follows (I've put ... where I couldn't see the elements in the view given above): datagrid ul li class=open Top level list item ul li Childless second level list item li Another childless second level list li class=closed Collapsed second level list item with children ul ... /ul li class=open Expanded second level list item with children ul li Third level list item li Another thid level list item li class=closed Collapsed third level list item with children ul ... /ul li class=open Expanded third level list item with children ul li Fourth level list item li Another fourth level list item /ul li A final third level list item /ul li class=closed Another collapsed second level list item ul ... /ul li A final second level list item /ul /ul /datagrid (Note that the /li end tags are implied.) Today this works except you can't open and close the items: http://junkyard.damowmow.com/333 In future browsers that support datagrid, you should see a tree view on that page. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Workers comments
So having read through the workers spec I have a number of fairly large
concerns.
The overall concern is that I think the spec is unnecessarily
complicated. I'll comment in detail below on specific features. An
overall requirement for mozilla is that we are very selective about
which features are exposed on the thread. For example exposing a full
navigator or window object is a huge amount of work. This doesn't mean
that it shouldn't be done, but there needs to be very good reasons when
exposing things.
So the first comment is the 'window' and 'self' properties. I don't see
a reason for these. I got a comment that they were there for easier
porting of code from the main window to a worker context. However just
having access to the window object is unlikely to help much. People
don't use the window object, they use properties and functions off of
it, such as window.location, window.name, window.document etc. So
without also adding these properties too I think it's unlikely that many
more scripts will run. Further I think having a property called 'window'
that doesn't return a true window object, with everything that goes with
it, is going to be a big source of confusion for developers.
On the subject of window. I think the fact that the global scope
interface is named something with 'Window' is very confusing for anyone
reading the spec. While I agree that there is some amount of association
between the global scope and the window, I think there is a much
stronger association between window and the properties that live on it,
such as window.location, window.document, window.frames, window.scrollX,
etc.
Additionally I am worried that sharing interfaces between the global
scope object for browser contexts, and the global scope object for
workers is going to lead to unnecessary feature creep with argument such
as the object is available in the browsing context, so why not make it
available in the worker context. I much rather want arguments like
this feature is needed in thread contexts because of reason X and use
case Y. This is due to the fact that making threadsafe
What is the use cases for the onconnect and onunload properties?
'onconnect' doesn't seem to add anything beyond simply leaving the code
outside any function. I.e. doing
function foo() { ... }
function bar() { ... }
function onconnect() { code here }
seems the same as
function foo() { ... }
function bar() { ... }
code here
The fact that the only way to communicate between workers and the main
browser context is through MessagePorts seems unnecessarily complex as
well as differing from how windows communicates using postMessage. I
think MessagePorts are a fine concept, but I don't think they should be
mandatory as I think in many cases they are more complicated than
needed. The whole concept of entangled message ports that clone and die
when you pass them around is something that I don't think we should
force upon developers unless absolutely needed. In the current draft I
can't even see how to reach the message port object inside the worker,
though that might be a temporary oversight. But it does indicate that
the level of complexity for communication is non-trivial.
A better model seems to be reusing what we do for window objects. Simply
make createWorker return a Worker object that has a sole .postMessage
property, and make it possible to pass a Worker object through
postMessage. We would also have to expose some way to send messages to
the main browsing context, either through a separate postMessageToWindow
function inside the worker context, or through a Worker object
representing the main browser context. This doesn't stop us from adding
support for MessagePorts as well, but it allows sites not to mess with
them unless needed.
In general I feel like the current draft is very far from the three
existing drafted APIs; the old google gears API, the new google gears
API and the API from mozilla. I would much rather start from any one of
those and make changes as needed based on use cases and experience from
those implementations. This should help both with ease of
implementation, as well as ease of porting code written for the existing
gears API.
/ Jonas
Re: [whatwg] pushState
On Sun, 3 Aug 2008, Jonas Sicking wrote: The problem I have with this is that it increases the number of possible user-visible behaviours and failure scenarios: - same Document, script knows how to handle data. - different Document, script knows how to handle data. - same URL, different Document, data ignored. - different URL, different Document, script knows how to handle data, but copying URL fails to work as expected. - different URL, different Document, data ignored. I'm actually more worried about the URL thing causing bugs than the data thing. * To avoid bad user experience behavior the site has to send almost exactly the same markup for both URLs, i.e. both for the page that called pushState, and for the page served for the URL in the URL argument in the pushState call. Equivalently though, to avoid a bad experience, a site will have to provide a statically generated URL version anyway, even if data is provided, to handle the bookmark case. * Entering a URL that is results in a 404 (or any other non-succcess value). This works fine when pushState is called, but fails on reload. Equivalently, if the author screws up the data handling but gets the right URL, then things will work fine in static browsing (with no JS) but as soon as you enable JS in a browser that does pushState(), things will break if you go back. Additionally, if we allow the data parameter to be preserved across Document recreations there is also: * Both URLs have to react the same way when a popstate event is fired. I am proposing getting rid of popstate and the data altogether. So I think we should either drop the URL argument entirely and say that URL transitions are too risky. This would fail to address one of the core use cases, namely bookmarkability, so this isn't really an option. Or we should leave the spec as is (but require that data is serializeable) and just encourage people not to transition between wildly different pages. Well I'm fine with leaving the spec as is, obviously, but if we have the data object, especially if it can only be used with one Document as in the current spec, I think it would be very confusing if exceptions were raised when things like elements were put into the data. It also seems like it wouldn't really gain us anything -- in the cross-session case (restarting the browser, etc) these data objects, according to the spec today, would be thrown out anyway. If we want to handle the cross-Document case (i.e. if we want to never have entries disappear from the session history) then I think we are better off just getting rid of the data argument altogether and always using the URL field. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
