Re: [whatwg] asking for UA developer's feedback on Content-Disposition filename I18N issue
Maciej Stachowiak wrote: I posted the mail below four weeks ago HTML WG's mailing list, hoping for feedback from Microsoft and Apple. All I got was some off-list feedback that wasn't really helpful, thus I'm reposting over here (trying to find out whether people over here are more receptive ;-). From those UA implementors who do not implement this, I'd like to find out what the chances are that this may be supported in future releases. What's holding you back? Are there any issues with the combo of RFC2616/RFC2183/RFC2231 that need to be addressed? On Apple's behalf, I can tell you that this seems like a generally useful feature and we don't know of any blocking issues in the RFCs OK, thanks for the clarification. themselves. However, per Apple policy I cannot comment on specific details of future releases. (I believe I said the same before). If you did I missed it. Anyway, thanks for the feedback. BR, Julian
Re: [whatwg] Errormessages in forms
On Mon, Jul 21, 2008 at 10:31 PM, Robert (Jamie) Munro wrote: Keryx Web wrote: label for=myfieldInstructions strong class=error Must be a valid value/strong /label input id=myfield etc / But presentationwise it should be displayed like this: Instructions [ (input) ] Must be a valid value [snip] What's wrong with: label for=myfieldInstructions/label input id=myfield etc / label for=myfield class=error Must be a valid value/label Can an input not have 2 labels? Or even: labelInstructions input etc strong class=errorMust be a valid value/strong/label -- Thomas Broyer
[whatwg] to use pixels a DPI should be defined in hader of each page
in now days we have different sizes of displays some of them huge with low
resolution and some of them normal but with very tiny dots.
usually the DPI of the development machine is matching the dpi of the VIEWER
but sometimes it doesn't
when progress comes and new displays with higher DPI are manufactured no one
buy them because all the text will be very small and unreadable.
i think the missing link between pixels and other real life measures is
missing.
maybe like:
meta name=page_dpi value=96
96 is a dipi of my LCD monitor.
72 is the dpi of crt monitor.
maybe to define it in css
@@set_dpi = 96
or
BODY {display-dpi:96;}
or
.mydiv {display-dpi:96;}
or
.mydiv {font-size:[EMAIL PROTECTED];}
or any how
the most common usage of pixel sizes is to match between the size of text
and images.
the images are in pixels and the fonts are in pixels and i want to
[left side image of text bar, align=baseline] some text [right side image of
text bar, align=baseline]
if the text is small everything is ok
but if the text get very large it usually displayed incorrectly.
i think pixels also want to grow when zoomed in but they also want to match
the sizes of images
second case that i can guess is fixed div positioning but here i am unsure.
what do you think about supporting dpi?
Re: [whatwg] to use pixels a DPI should be defined in hader of each page
On Tue, 22 Jul 2008, Shimon Doodkin Support wrote: in now days we have different sizes of displays some of them huge with low resolution and some of them normal but with very tiny dots. usually the DPI of the development machine is matching the dpi of the VIEWER but sometimes it doesn't when progress comes and new displays with higher DPI are manufactured no one buy them because all the text will be very small and unreadable. The CSS spec defines the pixel as a nominal 96dpi relative unit, to avoid this very problem. HTML5 uses CSS pixels whenever discussing dimensions. canvas supports higher resolution backing stores. This as far as I can tell HTML5 already deals with this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] re-thinking cue ranges
On Wed, 9 Jul 2008, Dave Singer wrote:
One of the features proposed for the next version of the video API is
chapter markers and other embedded timed metadata, with corresponding
callbacks for authors to hook into. Would that resolve the problem you
mention?
It may be that if we can define a way to embed cue-range-generating
meta-data in the media resource, with an abstract 'api' to get it out,
we'd deal with the only add by script issue here, yes.
Ok.
Overall, we remain concerned that typically it is the media author who
would define what the ranges are, not really the page or particularly
the script author. Media authors tend not to be happy writing scripts.
I totally agree, but that's what the in-media annotations, and future APIs
that deal with them, are for.
JavaScript is really the only concern from HTML5's point of view; if
other languages become relevant, they should get specially-crafted
APIs for them when it comes to this kind of issue.
The problem is that the current API more or less requires use of
closures and currying except for trivial cases. We don't think that is
good API design even for languages that have them. Perhaps at the very
least a cookie could be passed?
Done.
Secondly this mechanism is not very powerful. You can't do anything
else with the ranges besides receiving callbacks and removing them.
You can't modify them. They are not visible to scripts or CSS. You
can't link to them. You can't link out from them.
I'm not sure what it would really mean to link to or from a range,
unless you turned the entire video into a link, in which case you can
just wrap the video in an a href= element for the duration of
the range, using script.
Linking into a cue-range would be using its beginning or end as a seek
point, or its duration as a restricted view of the media (only show me
cue-range called InTheBathroom). Linking out of a cue-range would be
establishing a click-through URL that would be dispatched directly if
the user clicked on the media during that range (dispatched without
script). We agree that neither of these should be in scope now, but it
would be nice to have a framework that could be extended to cover these,
in future.
Jumping into a point of video is supported using other aspects of the API
(setting 'currentTime'); looping a certain part similarly has a dedicated
API ('loopStart' etc). I don't know that we'd ever want to use the cue
ranges for those purposes. I don't really understand the use cases.
Thirdly, a script is somewhat strange place to define the ranges. A
set of ranges usually relates closely to some particular piece of
media content. The same set of ranges rarely makes much sense in the
context of some other content. It seems that ranges should be
defined or supplied along with the media content.
For in-band data, callbacks for chapter markers as mentioned earlier
seem like the best solution.
For out-of-band data, if the ranges are just intended to trigger
script, I don't think we gain much from providing a way to mark up
ranges semi- declaratively as opposed to just having HTML-based media
players define their own range markup and have them implement it using
this API. It wouldn't be especially hard.
This seems to conflict with the answer (1) above, doesn't it?
How so?
Fourth, this kind of callback API is pretty strange creature in the
HTML specification. The only other callback APIs are things like
setTimeout() and the new SQL API which don't have associated
elements. Events are the callback mechanism for everything else.
Events use callbacks themselves, so it's not that unusual.
I don't really think events would be a good interface for this.
Consistency is good, but if one can come up with a better API, it's
better to use that than just be consistent for the sake of it.
It does seem strange that events are right in the spatial domain (mouse
enter/exit), but not in the temporal domain. Yet the basic semantic of
the english word event, let alone the web meaning, is pretty well
exactly matched by what is happening here -- crossing a temporal
boundary! Events are well-known and design uniformity suggests that
they be used, if nothing else.
An event is fired whenever a cue range is entered or exited (timeupdate),
but I really don't think events are appropriate for the cue ranges
themselves. To start with, it would decouple the range registration from
the event registration. It would also mean losing the ability to register
event listeners for cue ranges of a particular class rather than all of
them. I'm also not sure we really want the whole capture/bubble mechanism
for these callbacks, not to mention the ability for one callback to cancel
another one, etc. Events just seem like a very blunt and heavy weapon for
this task.
In SMIL the equivalent
Re: [whatwg] Errormessages in forms
On Mon, Jul 21, 2008 at 10:31 PM, Robert (Jamie) Munro wrote: What's wrong with: label for=myfieldInstructions/label input id=myfield etc / label for=myfield class=error Must be a valid value/label Can an input not have 2 labels? Thomas Broyer skrev: Or even: labelInstructions input etc strong class=errorMust be a valid value/strong/label Both of these suggestions lack the precision, the semantics and the flexibility of my suggestion. Vz Thomas B's solution: - What if a designer wishes to have the error messages grouped together on the top of the page, instead of next to the input fields and manages to come up with a solution that is very usable? - For the default UA error messages to be inserted correctly it must honour the classname as a microformat. Since that must be spec'd, it might just as well be a real element. Vz Robert M's solution: - Where would the UA put a default error message, in the first or second label? - How could assistive technologies differentiate between normal instructions and specific errors? Lars Gunther
Re: [whatwg] re-thinking cue ranges
On Tue, 2008-07-22 at 09:58 +, Ian Hickson wrote: On Wed, 9 Jul 2008, Dave Singer wrote: On Sat, 12 Jul 2008, Philip Jgenstedt wrote: Like Dave, I am not terribly enthusiastic about the current cue ranges spec, which strikes me adding a fair amount of complexity and yet doesn't solve the basic use case in straightforward manner. What are the use cases you think are basic? It's unclear to me what isn't being solved. Here's one use case, a slide deck: The most obvious use case in my mind is displaying captions/subtitles. I agree that proper events make a lot of sense here instead of callbacks. We could use some new event -- CueEvent maybe -- which would actually include the start and stop times and a reference to the target HTMLMediaElement. I might suggest a modified addCueRange which takes a data argument which is also passed along in the event object. Does the identifier argument address this sufficiently? Yes, it makes sense and should eliminate the need for closures in most cases. -- Philip Jägenstedt Opera Software
Re: [whatwg] Errormessages in forms
On Tue, Jul 22, 2008 at 1:55 PM, Keryx Web [EMAIL PROTECTED] wrote:
On Mon, Jul 21, 2008 at 10:31 PM, Robert (Jamie) Munro wrote:
What's wrong with:
label for=myfieldInstructions/label
input id=myfield etc /
label for=myfield class=error Must be a valid value/label
Can an input not have 2 labels?
Thomas Broyer skrev:
Or even:
labelInstructions input etc strong class=errorMust be a valid
value/strong/label
Both of these suggestions lack the precision, the semantics and the
flexibility of my suggestion.
Of course, I wasn't intending to dismiss your proposal with such code fragment.
I think however that if the user wants to let the UA handle validation
events, it should accept that the UA manage the UI; and I expect them
to overlay error messages (or use any other unintrusive mean).
Vz Thomas B's solution:
- What if a designer wishes to have the error messages grouped together on
the top of the page, instead of next to the input fields and manages to come
up with a solution that is very usable?
They handle invalid events in script. You can expect
libraries/frameworks to quickly add facilities for that as soon as
HTML5/WebForms2 start to be used and usable, such as:
$(#my_form).on(invalid).showErrors(#my_forms_errors, {
kind: bulletlist,
prefix: Please correct the following error(s) and then retry: });
- For the default UA error messages to be inserted correctly it must honour
the classname as a microformat. Since that must be spec'd, it might just as
well be a real element.
Or the default UA error messages could just be displayed the way the
UA chooses to display them (using baloon tooltips attached to each
invalid field, or using a thick red outline and only display the error
message in a tooltip on mouseover, etc.)
--
Thomas Broyer
Re: [whatwg] Web Sockets
On Tue, Jul 22, 2008 at 6:47 AM, Shannon [EMAIL PROTECTED] wrote: wait for connection; receive persistent connection request; pass request body to service; response = read from service; response_length = length of response; send Content-Length: $response_length; send $response close request or continue A threaded wrapper could queue multiple requests and responses. In theory (as I have yet to perform tests) this solution solves all websocket goals: [...] Asynchronous: Requests and responses can be pipelined, meaning requests and responses can be transmitted simultaneously and are queued. I think the problem is that this definition of asynchronous is very narrow. Yes, you don't need to wait for a request to finish before you issue a new one. But you'd still be bound to HTTP's request/response scheme in general. However, web authors might want to employ other schemes as well, for example server-sided asynchronous notifications (pushing), client-sided notifications that don't need to be replied or requests that can be answered out-of-order. Things like this could be implemented easily on top of the current WebSocket proposal, but would be very complicated to do with HTTP. If desired, maybe we could add an API to XHR to control pipelining though? Regards, Philipp Serafin
Re: [whatwg] HTMLMediaElement: more issues and ambiguities
On Thu, 10 Jul 2008, Philip J�genstedt wrote: The idea is that if you set the override to a 1:2 ratio, then each pixel of video data will be rendered 1:2. So you first have to normalise the width, getting rid of the influence of the official pixel ratio. No? I understand what the intention is, but think the terminology is confusing: - width given by the resource itself - height given by the resource itself - pixel ratio given by the resource itself I had thought that these 3 were actually orthogonal, such that the pixel ratio does not affect the width or the height. Instead, it seems that width/height is supposed to be aspect ratio pre-multiplied. This doesn't sit well with my intuition of what the self-given width/height of video is supposed to mean. If you open video in common media players the dimensions or width/height will be the physical width/height, not aspect-corrected width/height. Unless my intuition is severely broken, I think other will also assume what I have assumed. I've tried to make the spec generally much more explicit about this. Please let me know if the spec makes more sense now. I can definitely still change the terminology if you think it is still confusing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] re-thinking cue ranges
On Tue, 22 Jul 2008, Philip J�genstedt wrote: What are the use cases you think are basic? It's unclear to me what isn't being solved. Here's one use case, a slide deck: The most obvious use case in my mind is displaying captions/subtitles. I'd much, much ratio subtitles were done by the user agent natively based on captions actually included in the video data. We shouldn't rely on authors to provide accessibility features. Having said that, changing the code I gave in my last e-mail to support captions is pretty trivial -- simply add an exit callback that empties the current subtitles display. The rest is basically the same. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The iframe element and sandboxing ideas
The server must escape all user generated content by replacing with lt; etc. This is perfectly secure for all existing browsers. The sandbox instructs the browser to unescape. Completely fail safe for all. On 7/22/08, James Ide [EMAIL PROTECTED] wrote: I'm not sure that I follow - it seems to me that searching for unescaped text and failing is not a reliable solution. As you mention: The problem is 1: that the user can easily write /span in his comment and bypass the sandbox and 2: it is not backward compatible. Say I input /span and the application developer has forgotten to sanitize user input or permits use of the span tag (and has done some poor checking for well-formed code). The application may later display a page with my input, thus containing (e.g.): span sandbox=1 /span /span, where /span in the middle is my input. Is this a span element with unescaped content (/span), or is it malformed HTML? In my eyes, it's the latter and if any UA were to treat it this way, it would be trivial to inject more harmful code. On a side note, would comments be permitted inside a sandbox? Developers may wish to have this functionality, but there is also the concern of a malicious user submitting the string !--, which, from some brief testing, appears to cause problems in IE6 and possibly more UAs. I do not have significant experience with parsers so I can't say for sure if these issues are showstoppers but they raise some concerns. If the browser finds unescaped content inside a sandbox it should refuse to display the page - thereby forcing the author to fix this immediately. As mentioned previously on the topic of sandboxes, such a strict failing policy may not be desirable. Perhaps a more gentle approach is only not to render the sandbox's contents and perhaps display an error message in its stead. Overall, I'm seeing sandbox elements to be weak safety nets. AFAIK, there is no way for a UA alone to perfectly determine what is author- or developer-generated and what is user-submitted; user input must go through some santizing process to be completely safe. - James -- Sent from Gmail for mobile | mobile.google.com Best regards / Med vennlig hilsen Frode Børli Seria.no Mobile: +47 406 16 637 Company: +47 216 90 000 Fax: +47 216 91 000 Think about the environment. Do not print this e-mail unless you really need to. Tenk miljø. Ikke skriv ut denne e-posten dersom det ikke er nødvendig.
Re: [whatwg] HTMLMediaElement: more issues and ambiguities
On Tue, 2008-07-22 at 21:58 +, Ian Hickson wrote: On Thu, 10 Jul 2008, Philip Jgenstedt wrote: I understand what the intention is, but think the terminology is confusing: [snip] I've tried to make the spec generally much more explicit about this. Please let me know if the spec makes more sense now. I can definitely still change the terminology if you think it is still confusing. Thanks, that looks much better. -- Philip Jägenstedt Opera Software
Re: [whatwg] re-thinking cue ranges
On Tue, 2008-07-22 at 22:00 +, Ian Hickson wrote: On Tue, 22 Jul 2008, Philip Jgenstedt wrote: What are the use cases you think are basic? It's unclear to me what isn't being solved. Here's one use case, a slide deck: The most obvious use case in my mind is displaying captions/subtitles. I'd much, much ratio subtitles were done by the user agent natively based on captions actually included in the video data. We shouldn't rely on authors to provide accessibility features. Given how unreliable embedded subtitles tend to be in desktop media players (at least in my experience) I think it's very likely someone will write an JavaScript SRT parser library to use with this API rather than hoping that the embedded subtitles can be reliably detected in all different combinations of media frameworks and browsers. I guess standardizing on an embedded caption/subtitle format might be possible after we actually have decided on baseline codecs though... Having said that, changing the code I gave in my last e-mail to support captions is pretty trivial -- simply add an exit callback that empties the current subtitles display. The rest is basically the same. Indeed, I expect that some would even abuse the id parameter to pass the caption text directly, although that isn't very elegant. -- Philip Jägenstedt Opera Software
