Re: [whatwg] PDF version comments
On Nov 12, 2008, at 02:37, Ian Hickson wrote: The acks section shows question marks for 윤석찬 and 黒澤剛志. I presume this is a font problem; if someone can provide better fonts, I'm happy to try to hook them in. Droid Sans Fallback Regular is a free font that has glyphs for the above characters. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Issue when Video currentTime used for seeking.
On Wed, Nov 12, 2008 at 6:36 PM, Biju [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > toKeyFrame - optional, boolean, default false. if true indicates goto > the nearest keyframe of the value provided in secondsToSeek. > this is to improve performance while avoiding bug > https://bugzilla.mozilla.org/show_bug.cgi?id=463358 Good question. Should seeks go to the previous keyframe to the requested time, the next keyframe after the time, the closest keyframe, or the exact frame requested? Regarding that bug, I think it should be going to the last keyframe then decoding up to the point of the requested frame so it can display non-garbage data. But is there a requirement to be able to identify keyframes from JavaScript? I suspect not but don't know. > .seek() will return the time to which it is seek-ed to. What time is that exactly? Is that the time of the actual frame the seek ended on? Seek can take some time if it requires multiple http byte range requests to find the right location, and to search for the keyframe. You wouldn't want this to be a blocking call but it would need to be if you want to return the time. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Handling inside
On Tue, 11 Nov 2008, Garrett Smith wrote: > > > > Unfortunately, we have little choice in the matter. Scripting and XML > > both allow you to unambiguously create highly non-conforming DOMs, > > e.g. with elements as the root element and elements as > > children of elements. The renderer has to deal with all such > > DOMs. > > What does XML has to do with any of this? XML can denote arbitrarily nested DOMs. > A script that adds an HTML element to a INPUT element should cause an > hierarchy exception to be raised. No, it shouldn't. > | Since user agents may vary in how they handle error conditions, > | authors and users must not rely on specific error recovery behavior. > > http://www.w3.org/TR/REC-html40/appendix/notes.html#notes-invalid-docs This was one of the biggest mistakes in HTML4, and HTML5 does not make that mistake again. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issue when Video currentTime used for seeking.
On Wed, Nov 12, 2008 at 6:36 PM, Biju [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:
> video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";;
> video_element.currentTime=10;
> video_element.play();
You can use:
v.src = "foo.ogg";
v.addEventListener("loadedmetadata", function() { v.currentTime=10;
v.play(); }, false);
Chris.
--
http://www.bluishcoder.co.nz
[whatwg] Issue when Video currentTime used for seeking.
I see a problem while using video_element.currentTime instead of video_element.start ie, recent firefox nightly build removed video_element.start before that we could do following to make a movie with new URL start from 10th second frame video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";; video_element.start=10; video_element.play(); Now to achieve same effect I tried video_element.src="http://www.double.co.nz/video_test/ascannerdarkly480.ogg";; video_element.currentTime=10; video_element.play(); This gives a problem. ie, I can not set .currentTime immediately after .src changed it throughs error (may be it is waiting to load metadata) So can we have a method .seek() or .skip() or something. Syntax:- .seek(secondsToSeek, isAbosolute, toKeyFrame) Parameters:- secondsToSeek - optional, positive/negative floating point value to indicate seconds from current frame. Default 5 sec or a user set value. isAbosolute - optional, boolean, default false. if true indicate "secondsToSeek" is from the start instead of from current frame. toKeyFrame - optional, boolean, default false. if true indicates goto the nearest keyframe of the value provided in secondsToSeek. this is to improve performance while avoiding bug https://bugzilla.mozilla.org/show_bug.cgi?id=463358 Returns:- .seek() will return the time to which it is seek-ed to. so if seeking is true .currentTime - will give current position till where the video is already seek-ed .seek(0) - will give currently being seek-ed position. With out this extra method it will lot more Javascript code to archive the same. Cheers Biju
Re: [whatwg] Same-origin checking for media elements
On Wed, Nov 12, 2008 at 3:02 PM, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > On Wed, Nov 12, 2008 at 4:22 PM, Tim Starling <[EMAIL PROTECTED]> > wrote: >> >> JavaScript already has measures along the lines of (2), in the context >> of frames. The information a script can obtain about a frame from a >> different origin is carefully restricted. I think that a similar >> solution would be best. It has the advantage of consistency and proven >> security. > > > I would say it has a history of proven *insecurity*. Look at clickjacking > for example. > > Anyway, having discussed this with Hixie and Maciej and others a bit on > #whatwg, things seem to be leaning towards option 2. While my gut feeling tells me that this is the right solution - would you mind sharing some of the reasoning as discussed on irc? Thanks, Silvia.
Re: [whatwg] Handling inside
On Mon, Nov 10, 2008 at 7:59 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 10 Nov 2008, Tommy Thorsen wrote: > > On Mon, 10 Nov 2008, Tommy Thorsen wrote: >> >> From an implementors point of view, it's good to have clearly defined >> boundaries between modules. An implementation would typically have one >> module that tokenises and parses html and one module that renders the >> resulting dom to the screen. If all the unexpected input is dealt with >> in the parsing module, then you can make some assumptions in the >> rendering module which can greatly simplify the implementation. Having >> to deal with an arbitrary amount of illegal input in either module is, >> IMHO, not the ideal design. > > Unfortunately, we have little choice in the matter. Scripting and XML both > allow you to unambiguously create highly non-conforming DOMs, e.g. with > elements as the root element and elements as children of > elements. The renderer has to deal with all such DOMs. > What does XML has to do with any of this? A script that adds an HTML element to a INPUT element should cause an hierarchy exception to be raised. You have a choice: 1) leave DOM 1 alone; let the implementation throw an hierarchy exception. 2) make a standardized behavior for this case. | Since user agents may vary in how they handle error conditions, authors and users | must not rely on specific error recovery behavior. http://www.w3.org/TR/REC-html40/appendix/notes.html#notes-invalid-docs Garrett > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] Same-origin checking for media elements
On Wed, Nov 12, 2008 at 4:22 PM, Tim Starling <[EMAIL PROTECTED]>wrote: > JavaScript already has measures along the lines of (2), in the context > of frames. The information a script can obtain about a frame from a > different origin is carefully restricted. I think that a similar > solution would be best. It has the advantage of consistency and proven > security. > I would say it has a history of proven *insecurity*. Look at clickjacking for example. Anyway, having discussed this with Hixie and Maciej and others a bit on #whatwg, things seem to be leaning towards option 2. 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] Same-origin checking for media elements
Robert O'Callahan wrote: > Should and elements be able to load and play resources > from other origins? > > Perhaps Ian thinks not: > http://www.w3.org/Bugs/Public/show_bug.cgi?id=6104 > There's a to-and-fro discussion here: > http://lists.xiph.org/pipermail/theora/2008-November/001931.html > Jonas got involved here: > http://lists.xiph.org/pipermail/theora/2008-November/001958.html > > There are three obvious options: > 1) Allow unrestricted cross-origin / > 2) Allow cross-origin / but carefully restrict the API > to limit the information a page can get about media loaded from a > different origin > 3) Disallow cross-origin / unless the media server > explicitly allows it via the Access Control spec (e.g. by sending the > "Access-Control-Allow-Origin: *" header). > (3) is particularly nasty due to the incentive it creates for insecure configuration. We've seen this already with Flash policy files. Many administrators uploaded a crossdomain.xml with , not realising what sort of vulnerability they were opening up. It would be a shame to borrow security ideas from possibly the least secure client on the web, and to mandate those insecure ideas in browser standards. JavaScript already has measures along the lines of (2), in the context of frames. The information a script can obtain about a frame from a different origin is carefully restricted. I think that a similar solution would be best. It has the advantage of consistency and proven security. -- Tim Starling Wikimedia Foundation
Re: [whatwg] Show upload progress
On Fri, 5 May 2006, Joaquin Cuenca Abela wrote: > > A lot of people are implementing progress bars that show in real time > the upload status of files being uploaded. > > Right now it's a pain to implement that kind of functionality, as the > browser has to poll regularly the server with a secondary connection to > get the total size of the request, and the number of bytes already > received. > > Given that the browser already knows that information, I think it would > be great if it could expose it on some DOM object. What do you think? I think we may at some future point add an upload progress events object to elements, similar to what XHR is getting for upload. However, in the meantime, I think it would be better to ask browser vendors to make significant strides in improving the upload progress UI of form submission. There's really no reason browsers couldn't do this better than Web application authors could. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebForms2 validity
It's proposed below to remove checkValidity() -- if people have an opinion
on this, please do speak up.
On Tue, 28 Oct 2008, Eduard Pascual wrote:
> On Tue, Oct 28, 2008 at 8:09 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> > On Fri, 9 Feb 2007, Sean Hogan wrote:
> >>
> >> Many textual input form-controls would begin in one or another
> >> invalid state (valueMissing, patternMismatch) however authors would
> >> typically want CSS validity styles to apply only after
> >> checkValidity() - either a manual one or the automatic one performed
> >> by form-submission.
> >
> > Why?
>
> I agree with Sean's idea: at least on the initial state, controls
> showing up with "invalid" styling can be quite confusing to many users.
> It may depend a lot on the context, and even more on the user: although
> the initial "" for a required text field would be invalid, and even
> would make sense to visually convey that fact, many users may wonder
> "What did I wrong if I didn't do anything yet?".
The only way that text field would be invalid is if it had required=""
set; and in that case, one could disable the styling using :required to
change the styling in some appropriate way.
> The best solution I can think of this would be an additional
> pseudo-class, such as ":default", ":initial-value", ":non-modified", or
> anything like that (I'm really bad at naming stuff, so please take those
> only as *examples*, because that's what they are), which could be used
> together depending on the needs of each site or application, like this:
>
> :valid {
> // code for "green" higlighting
> }
> :invalid {
> // code for "red" highlighting
> }
> :default {
> // overriding code to remove highlighting (or to apply "white" highlighting)
> }
> :default:invalid {
> // code for "yellow" highlighting
> }
> That's just an example. The idea is that an application may need to
> convey (through styling the validity pseudo-classes) the meanings "you
> have put something wrong here" and "you have to provide something
> here" as different concepts.
That would be interesting. It is, however, out of our scope. :-) If you
want to follow up on this, I recommend bringing it up with the CSS working
group at [EMAIL PROTECTED]
On Tue, 28 Oct 2008, Philipp Serafin wrote:
>
> This seems to overlap with the "@placeholder" proposal. Maybe both
> proposals could be merged somehow?
>
> Ideas:
> a) Don't include :default but instead define :invalid so that it won't
> be set as long as the placeholder is visible;
> b) get rid of the placeholder attribute and use :default instead;
I don't really like the idea of making features interrelated in this way.
It makes things really complicated to spec, implement, test, and use.
On Tue, 28 Oct 2008, Nils Dagsson Moskopp wrote:
>
> make an easy rule into a complicated one to cater to an unknown use
> case. yeah. way to go.
>
Please don't be sarcastic on this list. :-)
> fact: invalid content is invalid. i'd use javascript to change the
> element class from "never given focus" to "had focus" using onclick in
> your case.
I agree that this seems like a better solution.
On Wed, 29 Oct 2008, Sean Hogan wrote:
>
> Ok. But what's the use of checkValidity() on form-control-elements?
> Isn't it just:
> function() {
>if (!this.validity.valid) this.dispatchEvent("invalid");
>return this.validity.valid;
> }
It's more like
if (this.willValidate && !this.validity.valid)
// dispatch invalid and return true
else
// return false
...but yes.
We could remove it, true. It's not that useful.
Do people want to keep it?
> > > Many textual input form-controls would begin in one or another
> > > invalid state (valueMissing, patternMismatch) however authors would
> > > typically want CSS validity styles to apply only after
> > > checkValidity() - either a manual one or the automatic one performed
> > > by form-submission.
> >
> > Why?
>
> I would probably now agree that the default should be immediate
> application of :valid / :invalid styling which can worked-around with
> script. The opposing view (what I would have said a year ago) is...
>
> I think that's the way it usually is now. More specifically:
> 1. It could be confusing to have :invalid styling on form-controls when the
> page first loads.
> 2. It could be distracting for the styling of a form-control to switch between
> :valid and :invalid while the user is typing into it.
> 3. It could be distracting for the :valid and :invalid styles to apply before
> the user tries to submit or explicitly requests the data to be checked.
>
> #2 can be worked around using :focus. I can't see how #1 and #3 can be worked
> around without script.
> A :validated pseudo-class that applied after checkValidity() is called or
> form-submission has been attempted would give some extra flexibility in the
> noscript scenario.
Most controls will be valid unless they are required, as far as I can
tell, so I'm not sure it's that big
Re: [whatwg] [WebForms2] custom form validation notifications
On Thu, 23 Oct 2008, Eduard Pascual wrote: > > On Thu, Oct 23, 2008 at 4:40 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > You can call setCustomValidity() to set a specific string. > Joao explicitly asked for a way to achieve this **without scripting > enabled**. I think it's quite obvious why setCustomValidity() doesn't > solve that need. Granted, but it's not clear how one could do custom validity checking without script, and for the other cases there are declarative solutions (min="" and max="" are self-documenting, for instance; and title="" can be used for pattern=""'s documentation.) > Would having some sort of "custom-error-message" attribute hurt that > much? (Of course, the name is just an example, and I wouldn't really > suggest it). It would simply ignored by current UAs, and not really hard > to implement (actually, it'd be trivial compared to implementing > reg.exp. parsing). It's not clear to me what problem this would solve. > >> If the UA has scripting disabled, trying to prevent the default > >> action for an invalid event won't work. Too overcome this problem, > >> there could be a new attribute which could be called > >> 'notifyoninvalid="true|false"' with a default value of true, for each > >> control, or for the entire form. If the value is false, then the UA > >> wouldn't notify the user in case of invalidity. This could then be > >> delegated to some CSS using :invalid; > > > > If scripting is disabled, why would you not want the user notified? > > That would be pretty bad UI. :-) > > That'd be really useful if validation can be delegated to server-side > scripting when no client-side scripting is available. You can do that today, just don't use the new constraint attributes. > Anyway, I don't think such an attribute is needed: a page can be > authored with a "catch-all" validation rule for the field, and then the > Javascript could update that rule upon the page's loading: if scripts > are dissabled, the rule wouldn't be updated and would stay as the > catch-all. I don't really follow. > OTOH, I think Joao's idea was more like to relying on visual hints (ie: > marking the field as red) on cases where an error message popup would be > redundant and annoying. I think that could be more elegantly handled > with an empty attribute value for an hipothetical "custom-error-message" > attribute (which is not the same as an absent attribute). I really don't follow this. Maybe some concrete examples showing the problem with the current spec solutions would help. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] About
(I've not replied to all the e-mails on this thread because they are mostly redundant with this one. Please let me know if you made a point regarding that you think needs changes to the spec that I missed.) On Fri, 17 Oct 2008, Mike Wilson wrote: > Anne van Kesteren wrote: > > > > For the table and lists cases, is there a good use case for > > complicating their content model > > This being a good or important use case is hard to say - I guess it is > one of these real-world annoyances that both webdevs and browsers have > learnt to cope with. As part of the HTML5 initiative is based on > real-world browser behaviour I was thinking this may be a candidate for > some spec adjustment in some form (maybe just defining graceful > migration). > > > or could you just as well put the input either before or after the > > table or list? > > For hand-coding I certainly could, I see no real reason to do what I > suggest here when you are in control of the complete markup. > > But it gets harder for the scenario I was mentioning in my initial mail: > [some incarnations of] server-side templating. Many templating systems > work with the whole page at once to specify what markup to generate for > specific data, but for more decoupled systems you may want to specify a > HTML snippet per object type or similar - and then apply recursive view > rendering on an object graph. I agree, but it seems that having the hidden inputs be inside the next of a list, or the next , or whatever is appropriate, isn't much to ask for. > Andy Lyttle wrote: > > This is something I wanted to do recently. I was building HTML in a > > Perl script, adding table rows in a loop, and I wanted some rows to > > contain text field with user-editable value, while for other rows I > > wanted the value to be displayed but not editable > > Yes, this is sort of similar to my scenario above, and you were able to > workaround it being in control of the whole markup in one place (and not > completely decoupled as I describe above). I think this is one of those > things that webdevs keep hitting every now and then, and it is caused by > a kind of inter- mingling of document structure and POSTable state in > HTML/DOM. For Perl, it's definitely possible (and relatively easy) to just store the hidden inputs until the next suitable place (e.g. the next cell). > Assuming you are in control of the whole page's markup at once then I > agree. But when you are not and, it may be far from trivial. (I > mentioned an example of this in the link I included earlier.) I don't really follow why it's so hard in that case, but maybe you should use a better templating language. :-) > Ian wrote: > > > - keeping the whole thing invalid but still define in HTML5 how > > > the migration of ill-placed :s should work > > > > That is theoretically already defined. > > Interesting. Is it the foster-parenting of tables you are referring to, > or is there anything more specific for :s? Yes, foster parenting, and also the form element pointer, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] PDF version comments
On Tue, 4 Nov 2008, Simon Pieters wrote:
>
> I had a quick look at the PDF version of the spec...
>
> The "check for updates" box should probably be hidden.
I've added:
@media print { #configUI { display: none; } }
...which should take effect at the next PDF update.
> Why are the status boxes in the margin hidden? It seems to me that they
> would be useful also on paper.
They're not hidden, they just don't exist. The boxes are generated by
script, which Prince doesn't run.
> The acks section shows question marks for 윤석찬 and 黒澤剛志.
I presume this is a font problem; if someone can provide better fonts, I'm
happy to try to hook them in.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Review of the 3.16 section and the HTMLInputElement interface
On Tue, 11 Nov 2008, Samuel Santos wrote: > >> On Thu, 6 Nov 2008, Samuel Santos wrote: > >> > > >> > If changing the button text can be a security issue (e.g. induce > >> > the user to an action that he's not aware of), we can come up with > >> > some solutions. > >> > > >> > What about allowing the Author to change the control's locale? By > >> > doing so, the UA can then render the button with the same locale as > >> > the application without compromising the security. > >> > >> It seems like browsers should do this already based on the lang="" > >> attribute. I recommend asking browser vendors to implement this. > > > > @lang will definitively fix the problem if browsers are willing to > > implement it. > > Ian, can I ask you to please check this with browser vendors? I don't think the problem is worth fixing, so I'm probably not the best person to convince them. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] event.message in workers examples
The workers examples use 'event.message' in a bunch of places, however the property is called 'event.data'. Same mistake in the "View this example online" pages. / Jonas
Re: [whatwg] Sections, headers, and styling
On Tue, Nov 11, 2008 at 5:33 PM, Eduard Pascual <[EMAIL PROTECTED]>wrote: > It is a quite common practice on current web pages to style the h1..h6 > elements to have them blend properly with the overall style of a site. > For HTML4/XHTML1 documents this is quite trivial; but with HTML5 the > "number part" of the heading element doesn't reliably define the > actual heading level anymore (specially when dealing with server-side > includes and / or user-provided content). I have tried to figure out > some CSS selectors to handle this task with HTML 5 documents and they > go completely crazy before getting anywhere near to being accurate: > there is an insane ammount of element-nesting combinations to keep > track of. Is there any sane way to deal with this basic need? > Generally you want to decide if you're going to use the numbered range, or just . If the former, just work it like you always would. If the latter, you have to do something like "h1 ~ section h1" to match what would otherwise be an h2. This will also match deeper headings, of course, so you want to put in the h3-equivalent selector as well, and possibly further. However, this is an interesting problem in general, that is perhaps best served by CSS itself. Perhaps something like a :heading(n) pseudoclass, which'll match headings of the given level. What qualifies as a heading, and how they nest and change levels, would be up to the markup language (html5 in this case). Vanilla html4 would just naively report as matching :heading(1), as matching :heading(2), etc. Html5 would match according to the heading-depth algorithm, and take into account both the number and the depth within s. ~TJ
[whatwg] Sections, headers, and styling
It is a quite common practice on current web pages to style the h1..h6 elements to have them blend properly with the overall style of a site. For HTML4/XHTML1 documents this is quite trivial; but with HTML5 the "number part" of the heading element doesn't reliably define the actual heading level anymore (specially when dealing with server-side includes and / or user-provided content). I have tried to figure out some CSS selectors to handle this task with HTML 5 documents and they go completely crazy before getting anywhere near to being accurate: there is an insane ammount of element-nesting combinations to keep track of. Is there any sane way to deal with this basic need? Greetings, Eduard Pascual
[whatwg] MessagePort close event and discarding a Document
Currently, HTML5 specifies that when a Document is discarded, "close" event should be asynchronously dispatched to MessagePorts that are entangled with ports belonging (in some specific sense) to this document. There is a race with garbage collection inherent to this requirement. Below I describe the issue in detail, and propose a solution. Suppose we have two browsing contexts, frameA and frameB, and two MessagePorts, portA and portB, owned by these contexts respectively. The ports are entangled with each other, and their queues are started. Further, portA is not reachable from live code, but has a "close" event listener (set via either onclose or addEventListener). Port portB is also unreachable, so garbage collection can destroy both ports. Now, we close frameB. This results in its document being discarded, so a "close" event is dispatched on portA (portA becomes GC protected when the task to dispatch it is posted). However, no event is dispatched if portA and portB are collected before the document is destroyed. The problem is that observable behavior depends on GC order, which it shouldn't. In practice, it is normally the same GC pass that destroys the Document and both unreachable ports, so a straightforward implementation is likely to crash due to using semi-deleted objects. I propose to remove the requirement to dispatch "close" event on the surviving port (#3 in paragraph 7.5.3.1). This is the only fix I can see, as making GC dispatch "close" to fix it from other side would suffer from basically the same logical problem. - WBR, Alexey Proskuryakov.
Re: [whatwg] Review of the 3.16 section and the HTMLInputElement interface
On Thu, Nov 6, 2008 at 6:17 PM, Samuel Santos <[EMAIL PROTECTED]> wrote: > On Thu, Nov 6, 2008 at 5:50 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > >> On Thu, 6 Nov 2008, Eduard Pascual wrote: >> > >> > I agree with Samuel in that this is an issue. In Catalunya, most often >> > Spanish software is used (both OS and browsers), because a lot of the >> > software is not easily (or at all) available in Catalan (specially >> > Microsoft software, such as Windows and IE, which ammount for a quite >> > big fraction of web surfers). Seeing Spanish stuff in pages that are >> > supposed to be in Catalan is quite annoying (especially when keeping in >> > mind some historic factors). >> > >> > I can understand that there may be some security concerns with this >> > control; but I don't think changing the "Browse" caption poses any >> > threat. But if there is so much paranoia on this, browsers could be >> > allowed (or even required) to ask for confirmation when picking a file >> > if the caption has been changed (something like "Are you sure you would >> > like to submit C:\example.txt to example.com?" should be enough, and >> > users would easily see such question as coming from the UA rather than >> > from the webpage). >> >> It has been shown that prompts are ignored by users, so that wouldn't >> really solve the problem. >> >> >> On Thu, 6 Nov 2008, Samuel Santos wrote: >> > >> > If changing the button text can be a security issue (e.g. induce the >> > user to an action that he's not aware of), we can come up with some >> > solutions. >> > >> > What about allowing the Author to change the control's locale? By doing >> > so, the UA can then render the button with the same locale as the >> > application without compromising the security. >> >> It seems like browsers should do this already based on the lang="" >> attribute. I recommend asking browser vendors to implement this. > > > @lang will definitively fix the problem if browsers are willing to > implement it. > Ian, can I ask you to please check this with browser vendors? > > >> >> >> >> On Thu, 6 Nov 2008, Eduard Pascual wrote: >> > >> > I was going to suggest this, but I don't think it's really doable: >> > browsers would need to include all the translations of that caption in >> > all their versions. In the specific case of IE, considering that >> > Microsoft tends to license only single-language versions of its products >> > (if you want it in two languages, you need to pay twice), I'm afraid >> > this would be an issue (despite the fact that IE is actually distributed >> > for free, it would still mess with their "packaging"). >> >> It's true that this may not be something browsers want to implement. >> >> -- >> Ian Hickson U+1047E)\._.,--,'``.fL >> http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. >> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >> > > > > -- > Samuel Santos > http://www.samaxes.com/ > -- Samuel Santos http://www.samaxes.com/
Re: [whatwg] script tag handling in "after head"
Henri Sivonen wrote: On Nov 11, 2008, at 13:27, Tommy Thorsen wrote: The assertion that the current node is still the head element pointer does not seem correct, as we push a script element onto the stack of open elements in the "A start tag whose tag name is 'script'" section of the "in head" insertion mode. This is http://www.w3.org/Bugs/Public/show_bug.cgi?id=6038 Ah, thank you. I hadn't really looked at that bugzilla before. I added my solution as a third possible fix. I think the first solution in the description of that bug sounds nice, but I'm not too fond of the second solution. (The one which involves sometimes popping one extra time.) Just my two cents' worth.
Re: [whatwg] script tag handling in "after head"
On Nov 11, 2008, at 13:27, Tommy Thorsen wrote: The assertion that the current node is still the head element pointer does not seem correct, as we push a script element onto the stack of open elements in the "A start tag whose tag name is 'script'" section of the "in head" insertion mode. This is http://www.w3.org/Bugs/Public/show_bug.cgi?id=6038 -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Errormessages in forms
Dne Mon, 10 Nov 2008 21:50:37 +0100 Ian Hickson <[EMAIL PROTECTED]> napsal/-a: Instructions Type in dd-mm- format Must be a valid value (if error is true) This seems excessively complicated and I'm not convinced there is really a problem to solve here. Just using plain text seems enough. Indeed it seems enough. Although this kind of solution could improve Screen Readers' abilities to effectively interpret forms. It could be finally clear how to code it right for both web developers and Screen Reader developers how (& what) to implement (I'm guessing here, I don't know how difficult it would be to implement such behavior). Nowadays, all kinds of hints & errors are outside the label element thus sreen readers don't read them out. That's bad. This could improve the forms & feedback accessibility in general. I'm not saying this is the best solution, if you have another, please share. I'm proposing those changes because current situation is horrible and nobody really knows how to code it right. An example: I'm sort of disgussed when I see how Zend Framework implements default form element wrapper-tags: dt's for labels, dd's for inputs and ul li's for errors. I think form elements (labels, inputs...) are not meant to be used in a definition list (because they aren't), errors (mostly one-line) are not meant to be in a list. Such abuse of html! Yes of course everyone does it differently, but I think people tend to do those kind of "evil" things when they don't have enough semantic tags to use. Just like solves those captionized pulled images - and replacing floated tables, divs or paragraphs - this could solve the how-the-heck-do-I-make-a-correctly-coded-and-accessible-form situation. If I'm mistaken again, or this issue has been already discussed, I apology for wasting your time. :) Take care, Ollie
[whatwg] script tag handling in "after head"
This one is kinda complex, but I'll try to explain the problem. The algorithm for handling script start tags in the "after head" insertion mode requires us to push the head element pointer onto the stack of open elements, then process the token using the rules for the "in head" insertion mode. Finally we are required to: Pop the current node (which will be the node pointed to by the head element pointer) The assertion that the current node is still the head element pointer does not seem correct, as we push a script element onto the stack of open elements in the "A start tag whose tag name is 'script'" section of the "in head" insertion mode. Alternatively, the script tag handling in "in head" could be interpreted to not require us to push the script element onto the stack of open elements, but then the following assertion in "An end tag whose tag name is 'script'" in "in CDATA/RCDATA" will not hold true: Let script be the current node (which will be a script element). In our implementation, I've chosen to implement the "A start tag token whose tag name is one of: 'base', 'link', 'meta', 'noframes', 'script', 'style', 'title'" as if it said: Parse error. Let /node/ be the head element pointer Push the node pointed to by the head element pointer onto the stack of open elements. Process the token using the rules for the "in head" insertion mode. Remove /node/ from the stack of open elements I haven't come across any problems with this approach so far... regards, Tommy
Re: [whatwg] Handling inside
Ian Hickson wrote: On Mon, 10 Nov 2008, Tommy Thorsen wrote: From an implementors point of view, it's good to have clearly defined boundaries between modules. An implementation would typically have one module that tokenises and parses html and one module that renders the resulting dom to the screen. If all the unexpected input is dealt with in the parsing module, then you can make some assumptions in the rendering module which can greatly simplify the implementation. Having to deal with an arbitrary amount of illegal input in either module is, IMHO, not the ideal design. Unfortunately, we have little choice in the matter. Scripting and XML both allow you to unambiguously create highly non-conforming DOMs, e.g. with elements as the root element and elements as children of elements. The renderer has to deal with all such DOMs. I just came across another related problem. Consider the following markup: TITLE My version of Firefox moves the title to head, Opera ignores the title completely, and the html 5 parsing algorithm produces the following peculiar markup: TITLE Should this title be allowed or ignored? Right now we ignore the start and end tags, but insert the CDATA into the select element. I'm tempted to ignore CDATA unless the current node is an option element in the "in select" insertion mode. Since we were discussing scripts creating unexpected DOMs, I had to try the following: function button_onclick() {document.getElementById('myselect').innerHTML = 'TITLE ';alert('title inserted'); } On Firefox, the title is inserted into the select element, but does not actually work. Opera seems to prevent the title element from being inserted into the select element altogether. -Tommy
Re: [whatwg] Handling inside
Ian Hickson wrote: On Mon, 10 Nov 2008, Tommy Thorsen wrote: FWIW: In our implementation, I've changed the handling of "base" and "title" in "in body" to: Process the token using the rules for the "after head" insertion mode. instead of processing them with the rules for "in head". Unless there are pages that depend on this (are there?), I'm very reluctant to change the spec in this way. No, I haven't seen any pages that depend on this. I'll revert this change in our implementation one day soon, and try to match Opera's behaviour instead.
