Re: [whatwg] Search-suggestions without scripting
On Sun, 14 Aug 2011, Timo Beermann wrote: The search-suggestions of search-fields as in Google or Wikipedia should be able without scripting, only with HTML/CSS. Because some users deactivate Scripting (for security or whatever other reason) and on other computers (school, university, work,...) you are not able to change the settings, even if you want to. E.g. I use NoScript and only allow scripting on very few trusted sites, that really need it. I looked into whether we should define a declarative solution for this, but I think that so far it seems that these autocomplete features are still very much evolving. For example, Google has been adding new things to their autocomplete regularly. In fact most autocomplete widgets seem to have some special feature that wouldn't easily fit into a generic declarative model -- consider Amazon's, where hovering over an item changes the department dropdown's selection without moving the autocomplete box, or Bing's, where typing weather inlines an interactive graphical weather box, or Apple's, where the items have an image and formatting. On Mon, 15 Aug 2011, Aryeh Gregor wrote: Scripting is generally necessary to get dynamic content. datalist can be used to provide search suggestions, but they'll be static if script is disabled. Proper suggest-as-you-type functionality is precisely the sort of thing that JavaScript is always going to be required for. Oh, I don't know. It's certainly plausible that this kind of thing will become commonplace enough and broadly similar enough that it makes sense to have a declarative way of specifying an autocomplete server, etc. But currently, we're still very much in the early days of this stuff. Things that can already be done in script are usually only be made into declarative features if they meet a very high bar: they must be *very* commonly used, and there must be substantial benefit to typical users (not just ones who disable script) from having them available as declarative features. Agreed. On Wed, 17 Aug 2011, Aryeh Gregor wrote: On Wed, Aug 17, 2011 at 4:12 AM, Alexandre Morgaut alexandre.morg...@4d.com wrote: I like the idea of a declarative way to support autosuggestions OpenSearch already made a successful specification supported by most browsers http://www.opensearch.org/Specifications/OpenSearch/1.1 That's an interesting point. There's no reason that autosuggest for browser URL bars and search inputs has to be any different. Given that all the infrastructure here is already present, a new attribute like suggestions=http://path/to/opensearch; would be all that's needed. It would be relatively easy for browsers to implement, and trivial for webpages to use if they're already using OpenSearch. I don't think this has to be related to datalist -- just have a new attribute on input. If opensearch's version of this was the widely used state of the art and people weren't still very much innovating in this space, I'd probably agree. Note that even in this space, though, it's not the end of the story. For example, Chrome does more than just list the search autocomplete results; it also loads the first suggestion in the background, and mixes in results from local history search, etc. Other browsers do similar mixing. While this works well for browser UI, where the browser can mix in all the various results together, when you are talking about a Web page you still end up needing script to do that. So having it declarative isn't necessarily a win. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Form input element for value-unit pairs
On Sat, 5 Mar 2011, Christoph P�per wrote: Imagine a richt text processor done in HTML5. If you want to select the font size (of a template or class, of course) how would you do it? Standalone word processors usually have a combo field that lets the user enter a number [...] possibly adding controls for increasng and decreasing [...] or they may allow the user to select one of the predefined recommended or frequent values. So far, input type=number handles these. In other places, software interface designers honor the variety of absolute and relative (length) units by introducing a widget that bears the number and the unit symbol, [...] Thus, would it make sense to add another new type for the input element? I think it would make sense to add something like this if we find that people do that kind of thing a lot. Currently you can get close using a type=number with a select; do sites do that? On Wed, 9 Mar 2011, Diogo Resende wrote: This is just a numeric input. It has a unit, just like a monetary value, but besides that it's just a number. Maybe a numeric input should have some type of formatting to proper show the unit (prefix/suffix, decimals places, decimal sep., ...). On Mon, 14 Mar 2011, Christoph P�per wrote: A new type is probably not necessary, because a new attribute that is called something like �unit� and is only valid in the �number� and �range� states could be enough. On Tue, 15 Mar 2011, Diogo Resende wrote: For me it would be great that a UA would implement an numberic input with a visible but unchanged unit. Something like an input+span but the span looking to be inside the input. [__12_pt_] ^-- cursor would not pass this point Extra: This is more interesting for other types of input, not necessarily numeric, like IPv4, currencies, HH:MM, .. That's an interesting idea, but it might be something we should leave to the Web Components work. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] classList should perhaps move from HTMLElement to Element
On Fri, 19 Nov 2010, Boris Zbarsky wrote: Given that SVG also has classes, it would make some sense to move classList from HTMLElement to Element. That way SVG, and any other languages that define classes (XUL comes to mind, actually) can benefit from it as well. Note that Gecko's current classList implementation lives on Element. How do you handle the difference between SVG and HTML's className? I think it would be confusing to have classList work the same on both but not className. (Currently, DOM Core and HTML both define classList; the former on Element and the latter on HTMLElement, because Anne and I disagree on what should happen here.) For the spec's purposes my plan is to follow whatever implementations converge on. Currently WebKit does what the HTML/SVG specs say (.className is a string in HTML, an object in SVG, and .classList is HTML-specific), Gecko does a mixture of DOM Core and HTML/SVG say (.className is a string in HTML, an object in SVG, and .classList is on both but returns null in unknown namespaces), and Opera does a different mixture (.className is a string in HTML, an object in SVG, and .classList is on SVG and HTML nodes but not on nodes from unknown namespaces). (Didn't have other browsers available to test on this machine.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, 28 Oct 2011, David H�s�ther wrote:
It would be more useful if the DOMTokenList methods (contains, add,
remove, toggle) would take a space separated list of tokens. This is the
behavior most DOM libraries have when dealing with class names.
So, when setting two classes, instead of
ele.classList.add(hey);
ele.classList.add(ho);
you could do
ele.classList.add(hey ho);
Currently, the latter results in an INVALID_CHARACTER_ERR.
The behavior of all methods should be obvious I guess.
This has now moved to DOM Core. If you still want this I recommend filing
a bug on that spec.
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
On Fri, 28 Oct 2011, Mike Taylor wrote:
I would prefer if it returned the DOMTokenList, to enable chaining like:
foo.toggle('bar baz').remove('bat');
That makes for very hard to read code, IMHO. I much prefer:
foo.toggle('bar');
foo.remove('bat');
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wed, 2 May 2012, Rick Waldron wrote:
On Wed, May 2, 2012 at 6:13 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 28 Oct 2011, David H�s�ther wrote:
It would be more useful if the DOMTokenList methods (contains, add,
remove, toggle) would take a space separated list of tokens. This is
the behavior most DOM libraries have when dealing with class names.
So, when setting two classes, instead of
ele.classList.add(hey);
ele.classList.add(ho);
you could do
ele.classList.add(hey ho);
Currently, the latter results in an INVALID_CHARACTER_ERR.
The behavior of all methods should be obvious I guess.
This has now moved to DOM Core. If you still want this I recommend filing
a bug on that spec.
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
On Fri, 28 Oct 2011, Mike Taylor wrote:
I would prefer if it returned the DOMTokenList, to enable chaining like:
foo.toggle('bar baz').remove('bat');
That makes for very hard to read code, IMHO. I much prefer:
foo.toggle('bar');
foo.remove('bat');
Mike's recommendation is the same API introduced by jQuery a few years
ago and since then, there have been many requests to expand the
signature to other jQuery APIs. The toggle('bar baz') is not a good
example, it should be illustrated with .add() and .remove():
It was the chaining I was talking about with respect to Mike's example,
not the multiple values.
Adding 1 class at a time is a _very_ common pattern in real world web
development.
As mentioned above, this API has now moved to DOM Core. If you still want
this I recommend filing a bug on that spec.
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] restricted palette for input type=color
On Mon, 7 Mar 2011, Markus Ernst wrote: A content management or blog system for a corporate website allows to set font and background colors. The designers define allowed color sets the way that the corporate design guidelines are respected, and that the text is always readable - e.g. three light color shades for backgrounds, and two corporate colors and black for text. You don't really need a colour picker for that... it's more a select than a colour picker. Or a series of radio buttons. If the presentation is more the concern, then we should probably rely on Web Components to solve the problem (styling a select with a new presentation, e.g.). While searching the list archives, I found a message from Ian Hickson: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017482.html He suggested to use a select element for the purpose of a restricted color set. Good to know I'm consistent. :-D (I wrote the reply to the above paragraph before reading this paragraph!) Here's why I think it would be worth to reconsider this position: - A select element would display color names or values instead of showing the colors, which does not make it a suitable UI for choosing colors. That's a presentation issue, though. We should let CSS and/or Web Components fix that; we shouldn't add new semantics for each desired presentation. - Restricting the color palette is actually almost as common a task, as defining start and end dates of a date picker, and for sure more common than defining a step in a date picker. Now we have the benefit of this specialized color input element, it is a pity if it lacks customization potential. The step in the date picker is something that was basically supported just because we had to define what step= did anyway since we had it for numbers. I don't disagree that it might make sense to limit the colour palette (e.g. only things with a brightness greater than 50%) for type=color. But that's a different use case, and a different feature, than the one given above. - The fact that most CMS do not have restricted color sets so far, does not mean there is no demand for it, but rather shows the difficulty of customizing tools such as TinyMCE. It is a hassle for CMS implementors (who are often not highly skilled JS programmers), if they are expected to respect corporate design guidelines. I don't follow. Right now (before type=color is widely implemented) it's easier to provide a limited set of colours than all colours. Surely then we should see more CMSes have restricted colour sets if it's a matter of difficulty. - I assume that restricting a color set in an existing color picker is not too hard to implement (of course I have no evidence for this assumption). That's, generally speaking, not a concern. On Tue, 8 Mar 2011, Jukka K. Korpela wrote: I guess this would then have to be an attribute of datalist, making it possible to restrict the set of available choices whenever a datalist is used. How about exclusive? I would expect this to be reasonably easy to implement and potentially useful for other input types, too. For example, consider a date picker. Quite often, whether trying to make dates or selling flights, there is a known set of (non-consecutive) days that are possible, so we would like to write, say, input type=date id=date name=date value=2011-04-01 list=datelist datalist id=datelist option value=2011-04-01 label=April 1st option value=2011-04-08 label=April 8th option value=2011-04-09 label=April 9th /datalist This is currently conforming, though no browser seems to make use of the datalist. A good implementation would open up a calendar for April, with only days 1, 8, 9 selectable and day 1 highlighted. Many existing applications use such interfaces, so there is apparent need for them. It certainly exists. How common it is, I don't know. It's a subset of sites with date pickers, which itself is a pretty small subset of sites with forms, which is a subset of pages. It's definitely something worth keeping in mind though as we look to where we might extend this feature. I haven't added it yet, because we're still not at a point where these form controls are very mature. If anyone wants this particular feature prioritised, a good way to start would be documenting existing sites that have date pickers that do this kind of thing. On Wed, 9 Mar 2011, Jukka K. Korpela wrote: Select is generic, like input type=text, as opposite to input type=date, input type=color etc. So an implementation cannot implement select in a content-aware way, like a date or color picker, but it can (and hopefully will, but it is not required to) implement e.g. input type=date with associated datalist as a date picker with some dates highlighted and possibly (when the proposed new exclusive attribute is used) all other dates grayed out. This isn't a complete
Re: [whatwg] Can we make checkboxes readonly?
. This may not sound appropriate for a checkbox because there are only two options, but consider if you had a Y/N field but if the Y option is chosen you wanted to record some other data in a hidden field because you didn't want it to appear in the table. For example you might have a field indicating whether a client wishes to be contacted via telephone, you might then have a popup value picker appear when clicking on the checkbox with 3 options 'No', 'Yes, contact anytime' or 'Yes, only during office hours'. The popup would cause the checkbox to be cleared if the first option is selected, and checked for the other two and a hidden field may be used to store the contact time preference. I would like to add that it would also be advantageous if checkboxes could be made readonly and in doing so follow readonly text inputs with regards to responding to and firing events like focus, blur, click etc. This has been a source of much frustration when trying to implement a spreadsheet-like table where onfocus, onblur and onclick events are used to highlight or unhighlight a cell, because disabled checkboxes do not respond to nor fire these events. Some consistency here with other input types like textbox would be very much appreciated. It doesn't sound like a checkbox control if it's not interactive. In similar situations, I've just made the table display the data with spans and characters or graphics for the status (check marks, etc), with the data stored in input type=hidden controls for submission. I think that's probably the better approach here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wed, 2 May 2012, Rick Waldron wrote: JS APIs like this should always return the object (constructed instance or not) and therefore chain implicitly. I understand that this is mostly a matter of taste in API design, but IMHO that's an anti-pattern. It encourages poor style; it discourages functional programming patterns, instead favouring state mutation patterns; it makes APIs harder to extend; it makes APIs that do have useful return values inconsistent with other APIs; it is, in fact, a layering violation: it attempts to shoehorn what should be a language design feature into the API layer. But I'll leave it up to the DOM guys to decide what to do for that interface. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Request for new DOM property textarea.selectionText
On Mon, 30 Apr 2012, Ojan Vafai wrote: On Sun, Apr 29, 2012 at 2:10 PM, Maciej Stachowiak m...@apple.com wrote: Aryeh is referring to the DOM Range interface, which can only apply to nodes that are directly in the DOM, and offsets into their text. The text contents of an input or textarea are not properly in the DOM, so you cannot use a DOM Range to reference such ranges. I am no sure this is what Ryosuke had in mind though; I think he just meant that in general we could support some notion of a range, and presumably we could come up with one that applies to contentEditable/designMode as well as to text controls. One extreme possibility is to simply change the definition of Range to allow it to address the contents of text input controls. I can't think of any approach to this that doesn't make Ranges much more complicated to work with. The way the old IE APIs deal with this is to have control ranges and text ranges. Control ranges are for form controls and images. Text ranges are kind of like DOM ranges, but a little less general. When you get the range from the selection, you get either a control range or a text range and all your code needs to be aware of which one it's got because they have slightly different APIs. I agree that the idea of one Range to rule them all sounds nice at a high-level, but I think in practice, you'll inevitably end up with something complicated like the IE ranges. The world is much simpler for browser vendors and web devlopers if Range is restricted to the DOM and text inputs just have special-cased APIs. Each API can focus on being good for its one use-case. Yeah, that's pretty much why I haven't gone that route. On Mon, 30 Apr 2012, Ojan Vafai wrote: I've added setRangeText(newText); // replace selection with newText setRangeText(newText, start, end); // replace given range with newText setRangeText(newText, start, end, action); // see below [...] This looks good to me. Could we just call the method setText though since the range values are optional. setRangeText, in retrospect, is wordy and confusing in a way that setText isn't IMO. We could even go fully jQuery style and just call the method text. I don't mind calling it something else, but as Aryeh points out, text or setText would make the common case (replacing the selection) really unintuitive to read. It does always affect a range, even if the range is implied by the lack of explicit start/end arguments. I'd also like to see us expose a method for getting the text that accepts optional start/end arguments. Mainly, this allows for the possibility of browser vendors to performance optimize (e.g. don't need to convert the whole string to a JS string just to get the 5 selected characters out). Is that really that expensive? Seems like it'd be better just to have UAs optimise their JS string implementations so that it can just be backed by the same thing as the DOM or the control's editor. (I believe Mozilla may in fact already do that.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Request for new DOM property textarea.selectionText
On Mon, 30 Apr 2012, Ryosuke Niwa wrote: Seems like it'd be better just to have UAs optimise their JS string implementations so that it can just be backed by the same thing as the DOM or the control's editor. (I believe Mozilla may in fact already do that.) In theory, this is possible. But any sort of proxy, etc... that lazily obtain the value (e.g. delaying it until substr, etc... is called) is hard to implement in practice because we need to serialize text before DOM is modified. e.g. 1 var inputValue = input.value; 2 var textUsed = input.value.substr(5, 10); In the above example, inputValue could be a proxy object. However, in the example below: 1 var inputValue = input.value; 2 input.value = 'bar'; 3 var textUsed = input.value.substr(5, 10); we need to serialize the string immediately before the statement in the line 2 is evaluated. That's just copy-on-write. It's hardly rocket science. :-P -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Exposing framerate / statistics of video playback and related feedback
/annotating/subtitling to the list of potential
applications. But also experiments and time-based interaction. Most
online ad-agencies have been using Flash to design eg. highly
interactive mini-sites where banners, etc. are shown or hidden based up
on the exact timing of the video. Also think projects such as
http://www.thewildernessdowntown.com/
If you could elaborate on these use cases, specifically detailing what
problems they expose that are not yet solved, that would be very helpful.
On Wed, 12 Jan 2011, Jeroen Wijering wrote:
With the step() in place, this would be a simple convenience function.
This pseudo-code is not ideal and making some assumptions, but the
approach should work:
function seekToTimecode(timecode) {
var seconds = convert_timecode_to_seconds(timecode);
videoElement.seek(seconds);
var delta = seconds - videoElement.currentTime;
while (delta 0) {
videoElement.step(1);
delta = seconds - videoElement.currentTime;
}
};
Why not just this?:
videoElement.currentTime = convert_timecode_to_seconds(timecode);
(Note that seek() and step() and similar APIs would be asynchronous,
so you couldn't implement the approach above as written.)
On Thu, 27 Jan 2011, Steve Lacey wrote:
The original suggestion for the video element looks good:
[Video Element]
// Frames decoded and available for playback.
unsigned long decodedFrames;
// Frames dropped during playback for performance reasons.
unsigned long droppedFrames;
But for the media element I'd like to propose raw bytes instead of a
rate as this allows the developer to construct their own rates (if
needed) based on whatever window they want. It would also be useful to
separate audio from video. A suggestion might be:
[Media Element]
unsigned long audioBytesDecoded;
unsigned long videoBytesDecoded;
Though this seems a little strange to have these specifically on the
media element as they reference particular media types. Another idea
would be to move these to the video element and also add
audioBytesDecoded to the audio element.
Another open question: what are sensible values if the information is
not available. Zero seems wrong.
Thoughts?
I'm still unclear as to what the use cases are, so it's hard to evaluate
this proposal.
On Thu, 31 Mar 2011, Silvia Pfeiffer wrote:
Please note that I've started a wiki page at
http://wiki.whatwg.org/wiki/Video_Metrics to try and collect all ideas
around media element statistics. Please add freely!
The use cases on this page aren't really use cases, especially for
decodedFrames and subsequent proposals. They just describe what the
attributes do, not what problem they solve.
On Thu, 27 Jan 2011, Steve Lacey wrote:
On Thu, Jan 27, 2011 at 3:53 PM, Chris Pearce ch...@pearce.org.nz
wrote:
Out of curiosity, why do you want this feature? What does it give you
that @buffered and @currentTime does not?
Being able to determine the bitrate that's currently being decoded has
been a request from devs (for similar reasons that devs on the FOMS list
have I expect). Raw data seems generally useful.
Can you elaborate on these reasons? Raw data is often interesting, but not
always useful. There's terabytes of data per second that we could be
exposing that we do not, due to lack of use cases.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] More feedback relating to dialog and modal section
On Thu, 29 Jul 2010, Ojan Vafai wrote (to www-dom): Use-case: Building modal DOM-based elements (e.g. modal dialogs) is very difficult right now. You need to capture and handle all sorts of events to cancel (e.g. tab, mouse events, etc). I've addressed this by introducing an inert attribute that you can use to indicate that a subtree of the document is inert. This effectively means that the parts of the document not so marked are modal. Instead, focusin/focusout should be cancelable. If either event is cancelled, it should cancel the focus change within the page. The UA is free, however, to blur the top-level window and, for example, focus the address bar. This allows sites to provide a modal experience in a reliable way, without a lot of code, but still disallows a web page from trapping keyboard focus. It's more than just focus, though. For example you want to disable buttons that respond to clicks, you want to stop it responding to drag-and-drop, you probably even want the browser's find-in-page to (by default anyway) avoid finding things in that area, etc. On Thu, 26 Aug 2010, E.J. Zufelt wrote: I am wondering if public discussion has been had over the concept of introducing a dialog element into html5. There is now such an element! Normally a modal dialog is created using scripting and CSS to restrict focus and activity within the modal segment of the DOM and to style the modal section of the DOM to appear as though it is a separate region floating above the remainder of the document. A modal element type could indicate to UAs that a segment of the DOM is to be treated as active, while the remainder of the DOM is to be inactive. Focus could be automatically set to the first natively focusable element within the modal segment of the DOM, or could be explicitly set through scripting. UAs could provide a default style for modals, as they do for other elements, but the developer would normally need to adjust the style using CSS for proper sizing and positioning. That's more or less how the new element works. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] On implementing videos with multiple tracks in HTML5
On Fri, 20 Aug 2010, Silvia Pfeiffer wrote: Three issues I have taken out of this discussion that I think are still open to discuss and potentially define in the spec: * How to expose in-band extra audio and video tracks from a multi-track media resource to the Web browser? I am particularly thinking here about the use cases Lachlan mentioned: offering stereo and surround sound alternatives, audio descriptions, audio commentaries or multiple languages, and would like to add sign language tracks to this list. This is important to solve now, since it will allow the use of audio descriptions and sign language, two important accessibility requirements. I think this is now resolved. Let me know if there's still something open here. * How to associate and expose such extra audio and video tracks that are provided out-of-band to the Web browser? This is probably a next-version issue since it's rather difficult to implement in the browser. It improves on meeting accessibility needs, but it doesn't stand in the way of providing audio descriptions and sign language - just makes it easier to use them. I'm not sure what you mean here. * Whether to include a multiplexed download functionality in browsers for media resources, where the browser would do the multiplexing of the active media resource with all the active text, audio and video tracks? This could be a context menu functionality, so is probably not so much a need to include in the HTML5 spec, but it's something that browsers can consider to provide. And since muxing isn't quite as difficult a functionality as e.g. decoding video, it could actually be fairly cheap to implement. I agree that this seems out of scope for the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Request for new DOM property textarea.selectionText
On Fri, 27 Apr 2012, Ryosuke Niwa wrote: All editing commands work inside input/textarea on WebKit although some of them have no effect (e.g. bold, italic, etc...) That sounds rather odd... I think reusing execCommand is better than adding new method for input/textarea elements for each new feature request like this one. If it was a contentEditable feature I'd reluctantly agree (reluctantly because execCommand is a terrible API), but I really don't see why execCommand() would work on input controls. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Request for new DOM property textarea.selectionText
On Sat, 28 Apr 2012, Ryosuke Niwa wrote:
On Sat, Apr 28, 2012 at 9:30 AM, Ian Hickson i...@hixie.ch wrote:
I think reusing execCommand is better than adding new method for
input/textarea elements for each new feature request like this one.
If it was a contentEditable feature I'd reluctantly agree (reluctantly
because execCommand is a terrible API), but I really don't see why
execCommand() would work on input controls.
Because they're all editing features.
They're very different in most sense, why should they be the same in this
one? (They have different DOM representations, different UI, different
events, different selection APIs, most of the execCommand()s only apply to
structured editors which neither input nor textarea have, etc...)
How do we know someone won't suggest adding things like
input.insertParagraph()
Well they can suggest it, but since text inputs are single-line editors,
they wouldn't get very far.
or input.deleteSelectedText(), etc...
That's one of the features setRangeText supports:
input.setRangeText('');
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Request for new DOM property textarea.selectionText
selection textobj.getRangeText(0) gives from start of text to current selection end textobj.getRangeText(null, -1) gives from current selection start to end of text Getting the text from a range is already rather simple (as demonstrated at the top of this e-mail), so I don't think that's necessary. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Request for new DOM property textarea.selectionText
On Fri, 27 Apr 2012, Ryosuke Niwa wrote:
Why are we adding this new API? WebKit already supports
document.execCommand('InsertText', false, new selected text);
That's for contenteditable regions, right?
The new API is for input and textarea. Also, it's not limited to
replacing the selected text, it can be any region.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [media] played member expected behavior.
On Thu, 26 Apr 2012, Paul Adenot wrote:
The played member [1] description of the media element states :
The played attribute must return a new static normalized TimeRanges
object that represents the ranges of the media resource, if any, that
the user agent has so far rendered, at the time the attribute is
evaluated.
Currently implementing this member in Gecko, we are wondering the exact
meaning of the 'rendered' term. If one seek in a video to a location
while being in a paused state, the user agent 'renders' the frame at
that location, since it is displayed on the screen. No audio (if any) is
rendered, though.
In that case, should we create an empty range starting and ending at the
time that was seeked to ? That means creating multiple empty ranges if
multiple seeks occur while being paused. Does the 'rendering' term
implies that playback should occur ? This description need clarification
to specify the exact behavior to adopt.
Semantically, the name of the member itself ('played') seem to imply
playback.
I think playback probably is the most useful. The use case here was
updating a playback scrub bar with colour for where the user has already
watched the video, and zero-length entries aren't useful for that.
I've made a note of this e-mail to fix the spec, but in the absence of
further information or opinions from anyone else, I'd go with playback as
you suggest.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Audio related feedback from years past
method leads to hacks, such as the one used in jsnes ( http://benfirshman.com/projects/jsnes/ ). Jsnes is a web application used for playing old NES games. It currently outputs sound by having a separate flash application read the sound from some variable. Other than that the application is java-script. Starting flash for playing the sound seems to drain lots of resources atleast on my computer. I bought my computer ~1 year ago. Yet I can not play the games with sound turned on using Chrome, which is supposed to have the best js-engine currently available. Without sound the game runs fine with plenty of cpu cycles left, but turning sound on changes the situation completely. Thus I believe that a standard way for producing sound would help both software users and developers. This sounds like exactly the kind of thing the efforts listed above now address. On Tue, 11 May 2010, Eoin Kilfeather wrote: A Google search on the discussion list returns the unanswered question from Keith Bauer (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024340.html) Actually that e-mail received a reply back in February 2010: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-February/025028.html I'm working on an application which has two separate channels of sound panned fully left and right in a stereo audio file. The application is for language learners and it would be very useful to set the audio pan position fully left or right to effectively mute one speaker. As the draft spec stands the only solution that presents itself is to split the stereo file into two and load two audio elements in the HTML. I haven't tried this yet but I suspect it will be a headache. Any chance of reviving panning? For the time being, I recommend relying on the APIs I mention above (or rather, their more widely implemented descendants) for panning too. However, if there are compelling use cases that would just need panning and nothing else, maybe it makes sense to add to the core media API too. Can you elaborate on your use case? Are they really two separate audio files that just happened to have been mixed together? On Fri, 28 May 2010, Charles Pritchard wrote: I'm exploring programmable MIDI, and would like to generate some discussion. Currently: audio src=data:audio/midi;base64,/audio is a valid way of generating a MIDI file; and if the browser actually supports midi, it can result in a playable stream. Live midi requires a data stream. I haven't added anything to enable MIDI control or playback from a Web page. It would be interesting to find out how much demand there is for this and whether the specs mentioned above will take care of this particular issue. So far, I have not seen much demand for it, but that doesn't mean we shouldn't eventually handle it. On Sat, 8 Aug 2009, Chris McCormick wrote: I'd like to reiterate the previously expressed sentiment that only implementing pre-rendered audio playback is like having a browser that only supports static images loaded from the server instead of animations and canvas tags. So what you're saying is that we should wait ten years from when we added audio before adding a way to do dynamic audio, right? Like we did with img and canvas. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Canvas] Text height
On Mon, 23 Apr 2012, Tyler Larson wrote: The measureText method in canvas' 2d context only returns the width of a span of text. Why not the height? Your information is out of date. :-) http://www.whatwg.org/specs/web-apps/current-work/#dom-context-2d-measuretext -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] createTBody on the table element.
On Mon, 23 Apr 2012, Alexis Menard wrote: I was looking at http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#dom-table-createtbody and I wonder why it was added. For now none of the browsers seem to implement it. I proposed a patch for WebKit but I'm wondering why this method exists as you can do what it does with the regular DOM API. Is it convenience? It was added to be consistent with createTFoot and createTHead? Consistency and convenience, yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Administrivia
Last year the W3C introduced a new framework for people developing specifications, which they call Community Groups (CGs). Since then we have moved a few parts of the HTML standard under CGs, most notably Aryeh's HTML Editing APIs specification [1], which replaced the old execCommand() spec in the HTML standard. The main advantage of doing this is that it means we have a clear patent policy. Historically, we've relied on the W3C HTML working group for this, but as the W3C has focused on stablising their HTML5 snapshot, newer features have not enjoyed the same coverage. To address this, today I have started the process of forming a community group for the rest of the WHATWG work. This will basically have no effect on how the WHATWG operates, except that when we make use of the W3C Community Group Final Specification Agreement (FSA) mechanism, anyone who wishes to co-sign the agreement [2] will be invited to do so. [1] http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html [2] http://www.w3.org/community/about/agreements/final/ -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] CSP sandbox directive integration with HTML
On Mon, 5 Dec 2011, Adam Barth wrote: I wrote some somewhat goofy text in the CSP spec trying to integrate the sandbox directive with HTML's iframe sandbox machinery. Hixie and I chatted in #whatwg about how best to do the integration. I think Hixie is going to refactor the machinery in the spec to be a bit more generic and to call out to the CSP spec to get the sandbox flags from the CSP policy. This is done now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Confirming understanding about window.location's interaction with sandboxed seamless iframes
On Wed, 11 Apr 2012, Adam Barth wrote: We ran into a tricky case in implementing seamless today, and I'd like to make sure we did the right thing. Consider the following markup: iframe seamless srcdoc=scriptwindow.location = 'http://example.com/';/script/iframe According to the rules for navigating seamless iframes, when the child frame assigns to window.location, the browser will navigate the parent frame. Now, what happens if you add in sandbox: iframe seamless sandbox=allow-scripts srcdoc=scriptwindow.location = 'http://example.com/';/script/iframe In this case, navigating the parent is blocked because the sandbox prevents the child from navigating it's parent. The blocking happens in step 2, which is before the seamless redirection which is in step 3, so in this case it's not blocked. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Dialogs and prompts
I just added a bunch of things relating to creating dialogs, popup
windows, inspectors, marking sections of applications as inert, and
related features to make it easier to build Web applications in HTML:
- dialog: an element to mark up windows.
- dialog.show(anchor): a way to show a dialog, anchored to a specific
element on the page.
- dialog.showModal(): a way to make a dialog modal.
- dialog.close(returnValue): a way to close a dialog.
- inert=: a way to disable an entire subtree, without necessarily
making the elements in that subtree appear disabled (e.g. the way that
controls behind a modal dialog are disabled without appearing that
way, in traditional UIs).
- dialog oncancel=: called when the user hits Escape on a modal
dialog, can be cancelled to make the dialog not close.
- dialog onclose=: called when the dialog closes.
- form method=dialog: a way to use form for completely client-side
interactions, including form validation, without having to worry about
the form submitting. (Until browsers support this, you'll have to also
specify something like action=javascript:void(0), unfortunately.)
These features were based on discussions on this list (some of which
are below), but also on the results of looking for existing use cases,
some of which are documented on this wiki page:
http://wiki.whatwg.org/wiki/Dialogs
The Fullscreen specification, also discussed on this list recently,
defines some of the features upon which these are built. Thanks to Anne
and Tantek in particular for working on that spec.
On Tue, 20 Mar 2012, Adam Barth wrote:
On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 19 Mar 2012, Jochen Eisinger wrote:
The motivation for this is that in a tabbed browser, modal dialogs
are potentially disrupting the work flow of the user as they can't
interact with any other web site as long as the modal dialog is
displayed.
Current browsers are having problems with the modal prompts:
Chromium for example doesn't display a window created by
showModalDialog in a modal way: http://crbug.com/16045
WebKit and Firefox don't suppress events while a modal dialog is
running: https://bugs.webkit.org/show_bug.cgi?id=78240 and
https://bugzilla.mozilla.org/show_bug.cgi?id=360872
Firefox displays modal prompts as tab-modal. However, it's possible
to execute JavaScript in a tab that should be blocked by a modal
prompt: https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the
prompts from separate tabs can block each other:
https://bugzilla.mozilla.org/show_bug.cgi?id=727801
All these issues are avoided by dialog's showModal(), which is
intrinsically async (all it does is disable the UI on the rest of the
page).
I'm not sure dialog addresses the same use cases as alert() and
confirm() because dialog is significantly more complicated.
== Non-modal confirm() ==
script
[...]
confirm(Are you sure you want to order the widget?, function(result) {
if (result)
sendOrder();
else
cancelOrder();
});
/script
== dialog ==
dialog id=orderConfirm
form method=dialog
Are you sure you want to order the widget?
input type=button value=Send onclick=sendOrder()
input type=button value=Cancel onclick=cancelOrder()
/form
/dialog
script
[...]
document.getElementById('orderConfirm').showModal();
/script
I don't think it's significantly more complicated, especially given the
gains.
Even after all that, you get a less functional experience in some
respects. For example, on Mac OS X, the Cancel button should be to the
left of the Ok button whereas on Windows they should be ordered as in my
example (i.e., with Ok to the left of Cancel).
Well, on Mac you shouldn't have an Ok button at all, it should be Send
or some such. So this problem exists with confirm() also.
On Tue, 20 Mar 2012, Boris Zbarsky wrote:
Perhaps confirm() should take (optional) labels for the two buttons?
If we were extending confirm(), that might make sense. However, as Maciej
says:
On Wed, 21 Mar 2012, Maciej Stachowiak wrote:
dialog will give a better user experience than even a non-modal
version of window.confirm() or window.alert(). Dialogs that are fully
in-page [...] are the emerging standard for high-quality page-modal
prompting.
I should add that this could be partly for path-dependent reasons, and
that if other technologies had been available, authors might not have
resorted to in-page modality with overlays. But I think the key missing
enabled was not asynchrony but rather the ability to fully control the
UI, layout and available commands of the modal experience.
Indeed. Most of the examples on the wiki page I cite above would be
non-starters with confirm(), even if we extended it with button labels.
alert() is mostly only used by either by sites with a low-quality user
experience, or as as non-production
Re: [whatwg] Dialogs and prompts
On Wed, 11 Apr 2012, Tab Atkins Jr. wrote: On Wed, Apr 11, 2012 at 4:26 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 29 Mar 2012, Darin Fisher wrote: Also, there is a downside to the current convention of custom drawing modal dialogs. Web pages that mash-up content from varied sources would need to have some convention for queuing up dialog requests. Ideally, modal dialogs should be shown in FIFO order rather than all at the same time. This seems like a tricky problem. It seems like something the platform could help with. I believe the dialog proposal helps here. I think non-blocking alert, confirm and prompt helps in a similar vein. The modal variant of dialog handles this (there's a stack of active modal dialogs). Note that dialog's model is FILO, while Darin was asking for FIFO. I'm not sure I understand when one would want to queue a dialog to show after another dialog has been closed. Does anyone have an example of that in a Web app today? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen and non-HTML elements
On Mon, Apr 9, 2012 at 4:58 AM, Charles McCathieNevile cha...@opera.comwrote: On Fri, 06 Apr 2012 16:51:30 +0200, Anne van Kesteren ann...@opera.com wrote: On Fri, 06 Apr 2012 16:25:20 +0200, Doug Schepers schep...@w3.org wrote: What's the rationale for restricting what authors (or users) can make fullscreen? You cannot render arbitrary SVG elements without a root svg element as far as I know. Sure you can - that's what zoom and pan does... Applying some preserveAspectRatio to determine *how* they fit into the fullscreen might be a handy feature creep... Pan and zoom pans, and zooms, a rectangular area inside an svg element. It does not individually render a specific SVG subtree. The SVG specifications do not define rendering for subtrees that are not rooted at svg elements (and rightly so; the svg element is needed to define things like the coordinate space). -- Ian Hickson
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, 9 Apr 2012, Jonas Sicking wrote: It seems clear to me that there is a use-case for sending a message to your parent frame, but only wanting to do so when your parent frame is from the same origin as you. That use case is already behind handled by ancestorOrigins, see the recent thread with Adam. WebKit is working on an experimental implementation. We're also going to expose the page's own origin; currently that's specced in Adam's URL spec but I expect that to be added to the HTML spec in due course. (I believe Adam posted about that recently too.) On Mon, 9 Apr 2012, Tyler Close wrote: The RPH handler doesn't need to know which is the legit site. The RPH handler just needs to know that it's getting the RPH data from the site that the user was interacting with, not some other unseen site running in the browser. Nothing we have discussed so far would provide such a guarantee. Indeed, I don't see how we _could_ provide such a guarantee. In the case you describe, the legit site framing the handler could just as easily spawn the handler via a scripted navigation as it could do so by waiting for the user to click the mailto: link. Putting the %s data in the window.location lets an attacker overwrite it. Only if it is in the fragment identifier. I whole-heartedly agree that it shouldn't be in the fragment identifier (it doesn't have to be -- if your mail client works offline using long-lasting cache headers, it's even easier to make it work using appcache). Assuming we merge the logic for the various register*Handler()s with Web Intents as I recently proposed, we also provide a way for the information to be accessible to a scripted handler, regardless of where the information is placed in the URLs. The important thing to understand here is that a communication channel that is vulnerable to tampering can be abused in unexpected ways. You don't need to tamper with the communications channel as far as I can tell. If you can navigate an iframe as you describe, then even if the mailto: information is put in the path or query component it would still be possible to do the attack you describe. Just wait for the iframe to appear and then navigate it to the mailto: handler with the parameters you want. That's exactly right! The whole window.location communication path is vulnerable to tampering, so we need some other way to communicate the RPH %s data, such as a DOM field. Honestly, I'm not really sure why you would use an iframe at all here. I certainly wouldn't trust a site that framed GMail and expected me to send e-mail that way. If they want me to send an e-mail, then let my mail client open in the top-level browsing context (ideally the current one, but failing that a new tab). With appcache fallback, it's not necessary to use only the URL fragment for an offline scenario to work, which makes talking about the URL fragment in this scenario extraneous. Assuming the mailto RPH handler is using appcache with a fallback, this whole scenario works if the %s data is in the path or query. The problem is that the whole window.location is a communication channel that is vulnerable to tampering within the browser. As far as I can tell, this is false. (The HTML spec is not especially good about describing the reality here, unfortunately.) The vulnerability is that window.location can be overwritten by other code running in the browser. Then we should fix _that_. This has nothing to do with register*Handler(). If window.location can be overritten cross-origin, then half the Web is broken -- e.g. GMail is full of iframes. If you could overwrite them with custom iframes at will, then spoofing would be trivial. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, 9 Apr 2012, Tyler Close wrote: On Mon, Apr 9, 2012 at 4:48 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 9 Apr 2012, Tyler Close wrote: The RPH handler doesn't need to know which is the legit site. The RPH handler just needs to know that it's getting the RPH data from the site that the user was interacting with, not some other unseen site running in the browser. Nothing we have discussed so far would provide such a guarantee. Yes, what I am proposing provides that guarantee. When an iframe is initially navigated to a mailto URL, the browser starts its RPH dispatch logic. In Firefox, this means a Picker dialog is shown and the user selects an RPH handler. The browser then navigates the iframe to the RPH handler URL and, under my proposal, would populate a DOM field containing the mailto URL. Nothing in the spec guarantees that a picker dialog is shown. Indeed, the specification is specifically designed to allow sites to be marked as default handlers, and in typical operation that would likely be the preferred behaviour for users. (Users don't typically want to pick a new PDF viewer or e-mail client every time they click on a PDF or mailto: link.) Alternatively, the browser could refuse to do repeated RPH navigation of the same iframe. That would break a use case such as a site with an index of PDFs opening in an irame, if the PDF viewer was a handler rather than a plugin. The vulnerability is that window.location can be overwritten by other code running in the browser. Then we should fix _that_. I was under the impression that the descendant policy on frame navigation was baked into the Web at this point and could not be changed. As far as I can tell, at least some browsers prevent anything but the fragment identifier being changed in certain cross-origin cases. I haven't studied this in depth recently, but I strongly suspect that the rules currently in the spec regarding access to Location object members (which block the access you are describing for scripted navigations as well as window.open() and target= navigations) do not need to be relaxed beyond merely allowing changes to fragment identifiers. As I mentioned, the implications if we do not limit them beyond this are far more dramatic than a site making a handler use a different URL. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Fri, 6 Apr 2012, Tyler Close wrote: On Fri, Apr 6, 2012 at 3:36 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 6 Apr 2012, Tyler Close wrote: Well if it's an iframe, the parent can't be anything but the original origin, as far as I can tell. What happens if the handler sends the postMessage to *, then the parent is navigated? Will the postMessage be delivered or not? A task queued on a Document is associated with that Document and can only be processed when that document is active. I'll assume that means it's not delivered, even though postMessage is a method on a Window, not a Document. Yes. See the event loop spec: http://www.whatwg.org/specs/web-apps/current-work/#event-loops Tasks are always associated with a Document, which must be active for them to be processed. In the case of window.open, it's true that the opener could have navigated by the time you try to communicate back. That's a general problem with window.open(), though; it's not specific to register*Handler(). The solution is to not use window.open(), which is in any case bad UI. A top-level window is the only context in which you can ask the user to engage in security-sensitive interaction, like entering a password, or making a selection that must not be vulnerable to clickjacking. Then, again, we should fix this at the window.open() level, not the handler level. It's not a problem specific to register*Handler(). The simplest way to address this, which doesn't require any spec changes, is for the opener to tell the window what origin to use, e.g. by opening an iframe to do the work and then having the iframe pop up the window, or by sending the origin in the URL, or using the postMessage() source attribute, etc. For such an example, you can just use a fallback section in the appcache manifest. (Or a fragment identifier, indeed.) Right, the obvious thing to do is use the fragment identifier, but that's got some security problems. With a small tweak we can make this safe and easy. I don't understand the security problem. Could you give a concrete example of an attack scenario? It is well-understood that URL fragment messaging is vulnerable to tampering between windows or frames in the browser. Boris already posted further clarifying this point and you seemed to understand. I don't know what you're confused about. I agree that there are ways to use Web technologies that are unsafe. For example, you could just allow people to inject arbitrary markup into your page. What I do not understand here is what the attack scenario is that is specific to register*Handler(), if there is one. Why would a mail client talk back to its opener? It might not, but some RPH handlers will. Why? What's the use case? So, it seems you're arguing that the Mozilla blog post was silly and developers won't try to solve problems that way. Is that so? I haven't read the blog post recently. I am quite willing to believe that it does things in an insecure manner; that does not, however, imply that there is not a secure way to do things. Well, perhaps it's not strictly necessary for you to understand it. If you want me to change the spec, I need to understand why. On Fri, 6 Apr 2012, Tyler Close wrote: On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Sep 2011, Tyler Close wrote: For example, a web mail program might have two registered RPH handlers for mailto: https://example.org/?from=me@companyq=%s; and https://example.org/?from=me@personalq=%s;. The user has configured their browser to send mailto links to their personal email editor. A malicious client page could directly open the URL for the company email editor. The web mail editor needs a way to detect when a client page is trying to subvert the user's chosen preferences. So, an RPH handler needs a way to know that it was loaded via the RPH dispatch. Once it knows this, it can also trust that the arguments in the URL, such as from in this case, were not tampered with by the client page. I don't understand the attack scenario. Sure, a Web page can open another Web page with arbitrary arguments. Why does it matter here? In the example above, the user is expecting that clicking a mailto link initiates sending of an email from their personal email account. The attack page bypasses the RPH dispatch and directly sends the user to their company email editor. ...then the user didn't click on the mailto: link, and the user's expectation regarding mailto: links is quite irrelevant. With the change I am asking for, the mailto RPH handler can detect that the RPH dispatch was bypassed and show UI that says: Hey user, this was an unusual request. Are you sure you want to use this account? Maybe you want to use one of these others. In the legitimate scenario, the mail handler page can assume that the user
Re: [whatwg] Fullscreen and non-HTML elements
On Fri, 6 Apr 2012, Anne van Kesteren wrote: The other day I was wondering whether I should change Fullscreen to not be applicable to all elements. I was thinking HTMLElement and SVGSvgElement (svg:svg) would probably be best. My reasoning was that it will not work for svg:rect and such. There's plenty of HTML elements that it doesn't make sense to fullscreen either -- e.g. source, any of the ones in head, any with a hidden= attribute, any marked display:none, etc. So we have to handle that anyway. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Fri, 6 Apr 2012, Tyler Close wrote: On Mon, Apr 2, 2012 at 4:39 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 26 Sep 2011, Tyler Close wrote: I was recently experimenting with the registerProtocolHandler (RPH) API and came across a couple of security gotchas that make it hard to safely use the API. One of these is already known, but AFAICT, hasn't been fixed yet. I haven't seen the other discussed yet. The Mozilla blog post that introduces the registerProtocolHandler API makes use of window.parent.postMessage to send a response from the RPH handler back to the client page. I presume it uses this in conjunction with an a href= link with a target= attribute to load the handler in an iframe. The client page loads the handler page using an iframe or a window.open(). Either can work. In the example code, the targetOrigin for this postMessage invocation is '*', while also noting that this is not secure. AFAICT, there is no API that the intent handler can reliably use to determine the correct targetOrigin for this postMessage invocation. How can the origin be anything other than the origin of the page that triggered the link? Exactly, but we need a way for the handler page to find out what that origin is. A client page on origin A causes a navigation to a RPH URL (iframe or window.open). The browser loads the user chosen RPH handler, which is another web page from origin B. After the handler page loads, it wants to send a return value back to the client page. How does the handler page know the client page's origin is A? It needs to know this origin string so that it can securely use postMessage to send the return value back. AFAICT, there is no existing API in the browser that lets the handler page determine the client page's origin. Well if it's an iframe, the parent can't be anything but the original origin, as far as I can tell. But in general, there's not expected to be any talking back. If you want something where the handler talks back to the page that provided the data, then you should use Web Intents. registerProtocolHandler() and registerContentHandler() are intended for things like mail clients (mailto:) or PDF viewers, which do not talk back. Indeed in the common use case, you just click the link and the entire browsing context gets replaced, so there's nothing to talk back _to_. Currently, the handler page can only specify * in the postMessage invocation that sends the return value. If the client page is navigated by an attacker, before the postMessage is done, the attacker can intercept the return value. It's the same rationale used every time we advise programmers against using '*' as the targetOrigin for a postMessage() invocation. That rationale only applies when you're going from window to window, not when you're going from iframe to parent. The second problem with RPH is that the handler page doesn't have a way of reliably getting the URL of the content to be handled from the browser. In order to work in offline scenarios, the RPH handler must put the %s placeholder in the fragment of its handler's URL. It's not clear to me that it makes sense to have an offline protocol handler. What kind of protocol do you have in mind? For example, consider an offline web mail program. I click on a mailto: link and want to compose a message in my web mail editor, queuing it to be sent next time I'm online. RPH is a way for a web page to send data to a user determined application. There will surely be many scenarios where offline functionality is desirable. For such an example, you can just use a fallback section in the appcache manifest. (Or a fragment identifier, indeed.) Unfortunately, this means that other content in the browser could modify the content URL before the handler reads it. Well, any content can load any URL, so it doesn't matter whether the URL is in the fragment identifier or the path or anything else, surely. It matters if the handler page assumes that the URL came from its parent or opener. The parent and opener then engage in a postMessage conversation where the parent knows it said one thing, but the handler heard it saying something different, something chosen by the attacker. Why would a mail client talk back to its opener? The intent handler sees a request coming from the victim page, but with a content URL specified by the attacker. A related problem is that the intent handler has no way to distinguish whether its URL was loaded via the browser's RPH handling, or whether the client page directly navigated to the intent handler's URL. Both of these problems could be fixed by adding another readonly DOMString to the API that contains the %s data for the RPH invocation. I don't understand why it matters how the URL was invoked. If the URL was invoked via RPH, then the handler page knows
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Fri, 6 Apr 2012, Tyler Close wrote: Well if it's an iframe, the parent can't be anything but the original origin, as far as I can tell. What happens if the handler sends the postMessage to *, then the parent is navigated? Will the postMessage be delivered or not? A task queued on a Document is associated with that Document and can only be processed when that document is active. But in general, there's not expected to be any talking back. If you want something where the handler talks back to the page that provided the data, then you should use Web Intents. registerProtocolHandler() and registerContentHandler() are intended for things like mail clients (mailto:) or PDF viewers, which do not talk back. Indeed in the common use case, you just click the link and the entire browsing context gets replaced, so there's nothing to talk back _to_. I was prompted to write the original email by a Mozilla blog post that suggested talking back. It also seems bad for web APIs to break under simple composition like this; especially when there's an easy fix available. I think it's unsurprising that a feature would not be suitable for a task for which it was not designed. Turns out canvas is really bad at cross- document communication too. ;-) In the case of iframe, there's no problem since you can't post anything to a parent that isn't the parent that spawned you. In the case of window.open, it's true that the opener could have navigated by the time you try to communicate back. That's a general problem with window.open(), though; it's not specific to register*Handler(). The solution is to not use window.open(), which is in any case bad UI. For such an example, you can just use a fallback section in the appcache manifest. (Or a fragment identifier, indeed.) Right, the obvious thing to do is use the fragment identifier, but that's got some security problems. With a small tweak we can make this safe and easy. I don't understand the security problem. Could you give a concrete example of an attack scenario? Why would a mail client talk back to its opener? It might not, but some RPH handlers will. Why? What's the use case? I don't understand the attack scenario. Sure, a Web page can open another Web page with arbitrary arguments. Why does it matter here? Two reasons: 1. An RPH dispatch is different from a direct load because it communicates a user choice to the RPH handler. I explained above how a handler might use this information. I don't see how this difference affects the security here. 2. An RPH dispatch comes from the browser, so URL parameters can be trusted; whereas they cannot be trusted in a load from another web page. I don't see how they can be viewed as trusted. With a small change, we can prevent a client page from faking an RPH dispatch to a handler page. It's just a page load, not a fake RPH dispatch. I don't understand the problem here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [media] startOffsetTime, also add startTime?
On Thu, 5 Apr 2012, Philip Jägenstedt wrote: On Wed, 04 Apr 2012 20:56:03 +0200, Ian Hickson i...@hixie.ch wrote: On Wed, 4 Apr 2012, Philip Jägenstedt wrote: In current Opera and Firefox the timeline is always normalized to start at 0, so the time that corresponds to 0 in the original timeline would be at a negative currentTime. I still don't really understand what you mean by start here. What I mean with normalized to start at 0 is that when playing the whole resource Now I don't understand what you mean by whole resource. :-) If a TV station starts broadcasting in October, and you join the stream in February, the whole resource is many months long. Where's your zero? (I guess it's academic if you plan on changing; I'm just curious.) Oh, whole resource is a bit of a misnomer, I really mean everything that we received. We don't make that distinction internally, since over HTTP there's no way to tell the difference between a streaming resource and a static resource served by a server that doesn't support byte ranges. The timeline is shifted by the timestamp of the first audio or video sample in the stream, such that currentTime is initially 0. The plan is to remove that adjustment. Ah, I see. Thanks for clarifying. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Wed, 4 Apr 2012, Michal Zalewski wrote:
In fact, in the vein of opt-in disclosure perhaps something like
discloselocation={none|origin|full} would be more convenient - in which
case, you get something like
window.parentLocations[n].{origin|href|hash|...}
I constantly fear that origin scoping for security mechanisms is too
coarse-grained in many use cases, because the complexity of what lives
in any single origin is growing pretty rapidly. Sites put
attacker-controlled content inside framed gadgets or advertisements, and
can't be reasonably expected to understand that if such a frame is
navigated to in a particular way, it may circumvent an origin-scoped
check.
Tab suggests (on IRC) that this should just be tied to sandbox=, which
seems reasonable at first blush.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 6:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- Some widgets want to behave differently depending on the context in which they are embedded. For example, a payment widget might want to send the user to a confirmation page for most web sites but might be confortable with a more streamlined user experience when embedded on a whitelist of sites with which they have a contractual relationship. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? From my original email: ---8--- 3) The widget could use postMessage to communicate with the embedder and to establish the origin of the embedder. However, this requires running code in the embedder that knows how to respond to the messages appropriately. If the widget provider supplies the code, then the embedder needs to trust the widget provider to run code in its origin, which is undesirable. If the embedder provides the code, then that greatly increases the complexity of embedding the widget (see 2(b) for a related discussion). ---8--- (This is what I get for jumping in a thread half-way rather than doing my usual wait til the end and read everything then reply to everything...) So is there any concern that there might be a hostile origin between a trusted top-level origin and a trusted parent origin? Top-level browsing context: victim-of-injection.example.org Contains: evil.invalid Contains: victim-host-of-victim-of-clickjacking.example.net Contains: victim-of-clickjacking.example.com Should we just expose the chain of ancestor origins in an array? My concern with exposing parent.location.origin to cross-origin frames based not on an origin check but on a are you contained test is that it is hard to define exactly who is allowed to access the member. For example, what if the entry script is actually in another window, but it calls a method in the iframe, and that method tries to walk the chain? Does it fail? What if the iframe calls a method on the window, and the window then tries to walk the chain? What if the window walks the chain without calling a method in the iframe? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [media] startOffsetTime, also add startTime?
On Wed, 4 Apr 2012, Philip Jägenstedt wrote: In current Opera and Firefox the timeline is always normalized to start at 0, so the time that corresponds to 0 in the original timeline would be at a negative currentTime. I still don't really understand what you mean by start here. What I mean with normalized to start at 0 is that when playing the whole resource Now I don't understand what you mean by whole resource. :-) If a TV station starts broadcasting in October, and you join the stream in February, the whole resource is many months long. Where's your zero? (I guess it's academic if you plan on changing; I'm just curious.) The spec changes around explicit timelines and static/streaming resources are a big improvement, thanks! However, it now talks about both explicit timeline and explicit timings in a way that makes me uncertain about Ogg. Ogg (at least without skeleton) is just a stream of timestamped packets, so the timeline simply spans the timestamp of the first packet to the timestamp of the last packet. WebM is similar in the streaming case in that timestamps the don't start at 0. Clarification of whether or not explicit timestamps (Ogg, WebM) implies an explicit timeline would be welcome. I assume that's the intention, which I also agree with. (Perhaps saying explicit frame durations instead of explicit timings would also help.) I've tried to change this. Finally, a typo: no explicit timings ofd any kind Fixed, thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen changes to support dialog
On Thu, 5 Apr 2012, Sean Hogan wrote: So the ::backdrop could be styled to not cover the whole page? Could it default to a top layer, but optionally be given a z-index? The ::backdrop specifically would just be immediately below its element in the top layer stack, at least as proposed. Could you elaborate on what your use case is for moving it to other layers? (Ideally with examples of dialogs that do this in the wild -- see the wiki page on which we designed the dialog feature -- http://wiki.whatwg.org/wiki/Dialogs -- for the examples that have primarily driven the design so far.) On Thu, 5 Apr 2012, Sean Hogan wrote: So this top layer prevents all user-interaction with the rest of the page? No, that would be inherent in the dialog showModal() behaviour. If that's the case, it seems a bit inflexible. I would imagine that some UI designers would like parts of the page to still be clickable - a couple of examples: - a toggle button to show / hide the dialog (probably part of a menu-bar). - a menu bar with buttons that, when activated, first dismiss the dialog Those sound like non-modal dialogs. Do you have any examples of modal dialogs on the Web that have these behaviours? As above, screenshots and URLs to such examples would be really helpful. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [media] startOffsetTime, also add startTime?
to go beyond the call of duty and support, say, animated GIFs, they can do so in an unambiguous way without having to invent ways around the spec's limitations. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Fullscreen changes to support dialog
So based on our discussions on IRC and in person earlier today, I think the following additions to the Fullscreen specification would provide the necessary infrastructure to support dialog: - Add a new stacking layer to the CSS 2.1 Appendix E layering model, after the current layer 10. Let's call this new layer the top layer. This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. An element in this layer is rendered in the CSS model as an atomic unit that is a sibling to the root element; overflow, opacity, masks, clips, etc, of ancestor elements do not affect it. Outlines must be rendered in their non-layer-10 position if they are specified on an element with an ancestor-or-self that is in such a stack. An element in this layer that has an ancestor-or-self that is display:none does not get rendered. The 'position' property for elements in one of these stacks computes to 'absolute', 'fixed', or 'center' if that is its specifed value, and to 'absolute' if the specified value is anything else. The containing block for such an element is the initial containing block, same as for the root element. The static position for left, right, and top are zero, unless overridden by another specification. (The dialog spec will override the static position for top.) - Define an algorithm to push an element onto the top layer, which adds a given element to this element's browsing context's viewport's stack, if the element is in a document. - Define an algorithm to yank an element from the top layer, which removes the given element from the stack it is in. When an element is removed from a document, it must be yanked from the top layer. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) Fullscreen then defines that when you make an element fullscreen, it's pushed onto the top layer, and when an element is unfullscreened, it's yanked from the top layer. The user emergency escape UI yanks all fullscreened elements from the top layer (but leaves any other elements in it; we wouldn't want dialogs to disappear when exiting full screen mode). If this works, then I'll use this for dialog. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: location.parentOrigin
On Tue, 3 Apr 2012, Adam Barth wrote: On Tue, Apr 3, 2012 at 4:32 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 3 Apr 2012, Adam Barth wrote: Talking with some folks off-list, there are also use cases for knowing the origin of the top-most document. Could you elaborate on those use cases? (And also those for parent.origin, though those seem more obvious, e.g. disabling features to protect against clickjacking in unauthorised embeddings.) The use case is the same as in the previous email, specifically: ---8--- Some widgets want to behave differently depending on the context in which they are embedded. For example, a payment widget might want to send the user to a confirmation page for most web sites but might be confortable with a more streamlined user experience when embedded on a whitelist of sites with which they have a contractual relationship. ---8--- The payment widget might care about all of its ancestors. For example, suppose the payment operator has a relationship with store.example.com. They might wish to fall back to using a confirmation page if store.example.com is embedded as a frame in another web site (e.g., pintrest). Why don't they just ask the parent frame for their parent's origin, since they trust them? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen changes to support dialog
On Tue, 3 Apr 2012, Ojan Vafai wrote: On Tue, Apr 3, 2012 at 4:14 PM, Ian Hickson i...@hixie.ch wrote: Fullscreen then defines that when you make an element fullscreen, it's pushed onto the top layer, and when an element is unfullscreened, it's yanked from the top layer. The user emergency escape UI yanks all fullscreened elements from the top layer (but leaves any other elements in it; we wouldn't want dialogs to disappear when exiting full screen mode). Escape usually calls cancel on dialogs, no? Seems to me that if you have a dialog open, esc should cancel the dialog, otherwise it should yank all fullscreened elements. Yes, indeed. I didn't mean to specifically refer to the escape key, so much as the generic escape me out of fullscreen mode because I might be being spoofed emergency escape UI. That could just be a button that appears when you hover over the top-right of the screen, for instance. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fullscreen changes to support dialog
On Wed, 4 Apr 2012, Robert O'Callahan wrote: On Wed, Apr 4, 2012 at 11:14 AM, Ian Hickson i...@hixie.ch wrote: This layer consists of a stack of elements, which each CSS viewport maintains. These stacks are initially empty. When the layer is painted, the elements in the stack are rendered in the order that they were added to the stack, with the most recently added being rendered closest to the user. The 'z-index' property is ignored for this stacking layer. Is each element in this stack treated as having its own stacking context? I assume so, but you'd better say so. Right, each one would be its own atomic stacking context much like a 'position:absolute' box normally is today. I agree this should be explicit in the Fullscreen spec. - Define a new pseudo-element ::backdrop which applies to any element in such a stack; it addresses a box that exactly covers the viewport immediately below the element in the stack, in the same stacking layer, whose only applicable properties are the 'background' properties. (Alternatively, make it a generic box with properties initially set to have position:fixed and positioned to exactly cover the viewport, but I don't see much point in letting people fiddle with this box's positioning, display type, etc.) It's probably more work to make all non-background properties inapplicable than it would be to simply treat it like ::before/::after generated content. Either is fine by me. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Invalid values of dir attribute causing change in appearance?
On Tue, 24 Jan 2012, L. David Baron wrote:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#bidirectional-text
specifies that UA style sheets should have the rule:
[dir] { unicode-bidi: embed; }
This implies that invalid values of the dir attribute should cause a
change in presentation. This seems wrong to me, on the general
principle that invalid values of attributes should be ignored. [...]
I tend to think that only the known values of the dir attribute should
cause the unicode-bidi:embed styling.
Fixed as suggested for all instances of [dir] in the UA style sheet.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] register*Handler and Web Intents
? On Tue, 21 Feb 2012, Bjartur Thorlacius wrote: Windows Explorer (the file manager) does for example offer users to edit images upon right-click. I worry that if URI scheme handlers need not only take care of fetching but also of presentation, other actions than view will be unnecessarily hard to implement. Thus I figure retrieval and presentation must be separated. I don't really see how you would tell the browser what the action is. As part of replying to this e-mail, I also reviewed the existing Web Intents spec. Here are some comments on it. I hope they are helpful. - Nothing seems to ever actually invoke the structured clone algorithm, so it's unclear when that should run. In particular, I don't understand when ports get cloned. Is it in the constructor? In startActivity? - What does it mean for a member of Intent to only be present at certain times? (e.g. Only present when the Intent object is delivered to the Service page) - A lot of the spec seems to be lacking in formal requirements; it just describes what happens but doesn't actually require it. - The spec requires that the interfaces that the Window object (called DOMWindow in the spec for some reason) implements depend on the markup in the page. This makes no sense, since the markup in the page isn't known at the time the interfaces are prepared, and even if they were, the page's content can change dynamically with elements being added and removed from script randomly. - Using URLs as intents, especially for the default intents, is overly verbose. I highly recommend just having a wiki page be a registry of widely used intents, and saying that if people want specialised ones for their own communities, they can then use URLs, but otherwise it's fine to just use simple identifiers like edit or share, so long as they are registered in the wiki. This is what we're doing with rel= and it seems to work fine. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, 26 Sep 2011, Tyler Close wrote:
I was recently experimenting with the registerProtocolHandler (RPH) API
and came across a couple of security gotchas that make it hard to safely
use the API. One of these is already known, but AFAICT, hasn't been
fixed yet. I haven't seen the other discussed yet.
The Mozilla blog post that introduces the registerProtocolHandler API
makes use of window.parent.postMessage to send a response from the RPH
handler back to the client page.
I presume it uses this in conjunction with an a href= link with a
target= attribute to load the handler in an iframe.
In the example code, the targetOrigin for this postMessage invocation is
'*', while also noting that this is not secure. AFAICT, there is no API
that the intent handler can reliably use to determine the correct
targetOrigin for this postMessage invocation.
How can the origin be anything other than the origin of the page that
triggered the link?
I suggest fixing this problem by adding a new readonly DOMString that
contains the correct origin for the postMessage invocation; perhaps
document.origin. So the response invocation would then be coded as:
window.parent.postMessage('my response data', document.origin);
Perhaps a different name or location is better for this field, so I'll
defer to the editor's judgment.
You can work out your own origin from window.location's members, but I
don't see how this helps you determine the origin of your parent. There's
a separate thread about adding a way to obtain your parent's origin, but
again, I don't see why you would need it in this case. Can you elaborate
on what the attack scenario you are envisaging is?
The second problem with RPH is that the handler page doesn't have a
way of reliably getting the URL of the content to be handled from the
browser. In order to work in offline scenarios, the RPH handler must
put the %s placeholder in the fragment of its handler's URL.
It's not clear to me that it makes sense to have an offline protocol
handler. What kind of protocol do you have in mind?
Unfortunately, this means that other content in the browser could
modify the content URL before the handler reads it.
Well, any content can load any URL, so it doesn't matter whether the URL
is in the fragment identifier or the path or anything else, surely.
For example, an attacker could open a window on a victim web page. The
victim web page then opens an iframe on a content URL that triggers
RPH. The attacker then navigates the iframe so that its
window.location contains a different content URL.
How can the attacker navigate that iframe? Surely it would not be allowed
to navigate it, per the allowed to navigate definition in HTML.
The intent handler sees a request coming from the victim page, but with
a content URL specified by the attacker. A related problem is that the
intent handler has no way to distinguish whether its URL was loaded via
the browser's RPH handling, or whether the client page directly
navigated to the intent handler's URL. Both of these problems could be
fixed by adding another readonly DOMString to the API that contains the
%s data for the RPH invocation.
I don't understand why it matters how the URL was invoked.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [media] startOffsetTime, also add startTime?
On Fri, 9 Mar 2012, Philip Jägenstedt wrote: On Thu, 08 Mar 2012 19:16:40 +0100, Ian Hickson i...@hixie.ch wrote: On Thu, 8 Mar 2012, Philip Jägenstedt wrote: I suggest the property offsetTime, defined as the stream time in seconds which currentTime and duration are relative to. I don't understand what this means. The currentTime is relative to the media timeline, which is UA-defined and should be based on the media timeline. The BBC wrote a blog post [1] about how currentTime varies between Firefox and Chrome. Opera does the same as Firefox here. You're right, however, that the way media timeline doesn't make any guarantee that currentTime starts at 0 or that duration is the duration. I think that the implementations predate the media timeline concept, and I agree with the BBC blog post that the Opera/Firefox behavior is better. Controls written assuming that currentTime goes from 0 to duration won't break and duration will actually mean duration. Controls written assuming that currentTime goes from 0 to duration are going to look mighty ugly when dealing with infinite streams where the browser is only buffering the last 30 minutes, DVR-style. I don't think this is a sane assumption. Or to put it another way: currentTime does always go from 0 to duration, and duration could be Infinity; but at any particular time, only a part of that is a seekable range. In practice it would often be understood as the time since the server began streaming and would be useful to sync live streams with out-of-band content simply by letting the out-of-band content be relative to the start of the stream. That should be zero. I can change that to a must if you like; it's a should because in some cases (e.g. MJPEG) you don't know what the media timeline is or how to interpret it, so there's no way to do it. Which should are you referring to here? If the media resource somehow specifies an explicit timeline whose origin is not negative, then the media timeline should be that timeline and In the absence of an explicit timeline, the zero time on the media timeline should correspond to the first frame of the media resource. I really don't know what startOffsetTime is intended for. AFAICT it's a piece of metadata that you could just as well provide out-of-band, but for convenience it is exposed via the DOM API. I think it could be handy to have and would like to implement it, but I don't understand if it's any different from other metadata like producer or location of a video. The startOffsetTime is useful for controllers who want to display a controller with real times, e.g. like TiVo's DVR UI, even when the underlying media resource has some more or less arbitrary timeline. e.g. if a TV station starts broadcasting on some Friday at 2pm, that would be its zero time for its timeline, but eight months later, a user joining that stream doesn't care that the stream is 21 megaseconds old -- they just want to see 14:20 as the time that corresponds to what was streaming at 2:20pm. However, knowing the date of a video is still useful, potentially even for the streaming case, so we do want to expose the DateUTC field from WebM. However, startOffsetTime is a bad name for it, since it's not using the same unit as currentTime. I suggest offsetDate, to go with offsetTime. I don't mind renaming startOffsetTime if people think that would help. I don't think offsetDate is any clearer though. How about mediaTimelineOriginDate? Simply originDate or startDate, perhaps? Ok, I renamed it to startDate. It could also do with a good example. The spec says: If the media resource specifies an explicit start time and date, then that time and date should be considered the zero point in the media timeline; the timeline offset will be the time and date, exposed using the startOffsetTime attribute. I interpret this as a date at currentTime=0 in the spec's definition of currentTime Right. and currentTime=-initialTime (unless media fragments are used) in the Opera/Firefox definition of currentTime. Not sure what this means. However, there's a weird spec example which can lead one into thinking otherwise: The startOffsetTime attribute would return a Date object with a time corresponding to 2010-03-20 23:15:00 UTC. However, if a different user agent connected five minutes later, it would (presumably) receive fragments covering timestamps 2010-03-20 23:20:00 UTC to 2010-03-21 00:05:00 UTC and 2010-02-12 14:25:00 UTC to 2010-02-12 14:35:00 UTC, and would expose this with a media timeline starting at 0s and extending to 3,300s (fifty five minutes). This seems like a rather atypical streaming scenario. It would be a lot nicer if the single example of startOffsetTime was for the common scenario where each client gets the same stream that thus has the same timeline and the same
Re: [whatwg] Fixing two security vulnerabilities in registerProtocolHandler
On Mon, 2 Apr 2012, Boris Zbarsky wrote: On 4/2/12 7:39 PM, Ian Hickson wrote: For example, an attacker could open a window on a victim web page. The victim web page then opens aniframe on a content URL that triggers RPH. The attacker then navigates theiframe so that its window.location contains a different content URL. How can the attacker navigate that iframe? Surely it would not be allowed to navigate it, per the allowed to navigate definition in HTML. As far as I can tell UAs seem to allow walking window.frames for any window you have a reference to without performing any same-origin checks, so you can walk your way down the frame hierarchy and then set location.href, which is allowed cross-origin. I don't see any sort of allowed to navigate check happening on the href set in UAs, but maybe I'm testing it wrong? Ah, yes, good point, I forgot that the attacker would have a reference to the Window object. Seems like it would be just as easy to just register a protocol handler though. I mean, why would the victim assume it trusts the handler in this scenario? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Canvas v5 API additions
are describing is a symptom of this WebKit bug, fixed in the WebKit source code on 2011-10-26 I agree with Darin's assessment here. Let me know if you still think the spec should be changed. On Fri, 13 Jan 2012, Jeremy Apthorp wrote: I'd like to draw non-antialiased lines in a canvas. Currently it seems that the only way to do this is to directly access the pixel data. Is there a reason there's no way to turn off antialiasing? What's the use case? On Sat, 28 Jan 2012, Bronislav Klu�~Mka wrote: On 27.1.2012 20:02, Ian Hickson wrote: On Thu, 20 Oct 2011, Bronislav Klu�~Mka wrote: Would it be possible to extend canvas specification to include scroll bar functionality? To add scroll bar, to manage scroll bar (total size, page size). Creating control based on canvas that needs scrollbar at this point is unnecessarily difficult at this point. It is expected that the component model feature being discussed in the public-weba...@w3.org mailing list will be how you make widgets on the platform. You wouldn't want to put the scrollbar in the canvas itself, since then it wouldn't follow platform native conventions, for example. Instead, you would create a widget which uses overflow:scroll with an element of the right height or width to create scrollbars, and then you would react to scroll events to repaint the canvas. How does scrollbar on div, p, textarea etc. follow platform native conventions but scroll bar on canvas would not? I presumed you meant a scrollbar drawn by the author. If that's not what you mean, I don't understand your proposal. Could you elaborate? On Thu, 20 Oct 2011, Bronislav Klu�~Mka wrote: b) how about creating user controls using canvas? (rich controls are better doing this way, one has pixel perfect control, full browser compatibility) like document viewer, rich listview/treeview control... Generally speaking, canvas isn't intended for anything but the simplest of interactive controls. Generally speaking, widgets are intended to be HTML container, which makes them far inferior to possibilities of canvas... simpler, but inferior (as is any HTML container at this point). I'm not sure I follow. What is the use case you had in mind? On Tue, 31 Jan 2012, Charles Pritchard wrote: I'd like to see scrollTop and scrollLeft supported for the Canvas element. They would simply fire an onscroll event on the element, and do nothing else. Many Canvas UIs use only one visible canvas layer, or otherwise, one main canvas layer. It'd be quite handy to be able to use the scrollTop and scrollLeft setters, and as an author, hook into canvas.onscroll to identify when updates ought to be painted. Currently, authors can create a large canvas, and place it in a div: div style=overflow: hidden canvasThis can is larger than the div/canvas /div It would be great to be able to respond to scroll events, such as Element.scrollIntoViewIfNeeded and/or ctx.scrollPathIntoView, and simplify the model in the future. div canvas onscroll=repaint(scrollLeft,scrollTop)This canvas is the same size as the div and responds to onscroll/canvas /div The values for scrollLeft and scrollTop would be in css pixels, as they are for other elements, and when set, they would trigger an onscroll event, as usual. On Sat, 4 Feb 2012, Anne van Kesteren wrote: That would require special casing canvas in http://dev.w3.org/csswg/cssom-view/#scroll-an-element which I'm not sure is a good idea. Why don't you just dispatch a synthetic scroll event? On Sat, 4 Feb 2012, Charles Pritchard wrote: Does the scroll event carry x/y information? I agree, this is a special case for canvas -- the precedent set by input type=text is that form controls may have separate scroll semantics. My proposal is not thought-out all the way, but I'm hoping it can float. The idea here is to enable scroll with limited height/width canvas layer to work well. This is going to be useful for context.scrollPathIntoView as well as simply running Element.scrollIntoView on elements within the Canvas sub-tree. Currently, the scroll* attributes in Canvas are read only and set to zero. So, I think there is room to support them in the future. I don't really understand the use case here. Could you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas v5 API additions
On Thu, 29 Mar 2012, Ashley Gullen wrote: BTW: - have you got a link to the spec including the smoothing property? can't seem to find it http://www.whatwg.org/specs/web-apps/current-work/#dom-context-2d-imagesmoothingenabled (I will be replying to your detailed feedback at some future point, but I wanted to make sure you had the link now in case you had any more feedback!) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox attribute
On Mon, 26 Mar 2012, Ian Melven wrote:
While working on implementing HTML5's iframe sandbox, I realized that in
script, one can't tell the difference between these two cases : iframe
and iframe sandbox = ''.
In both cases, iframe.sandbox will be '' (the empty string). This is
true in Webkit and IE10's implementations, as far as my testing can tell
(and in my work-in-progress implementation for Firefox also).
Just use iframe.hasAttribute('sandbox').
The same applies to a lot of attributes in HTML, the situation is not
unique to the sandbox= attribute. I don't think we need to change it to
address this issue, since there is already an API for it.
HTH,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] translate attribute conflicts with http://www.winktoolkit.org/documentation/symbols/HTMLElement.html#translate
On Mon, 26 Mar 2012, Adam Barth wrote: WebKit recently implemented http://www.whatwg.org/specs/web-apps/current-work/#attr-translate, but that caused us to break orange.fr on mobile: https://bugs.webkit.org/show_bug.cgi?id=82246 The problem is that http://www.winktoolkit.org/documentation/symbols/HTMLElement.html#translate has a the following code: if (wink.isUndefined(HTMLElement.prototype.translate)) HTMLElement.prototype.translate = HTMLElement.prototype.winkTranslate; The web site expects HTMLElement.prototype.translate to be Wink's translate function rather than the HTML translate attribute. Would it make sense to change the name of the translate attribute to avoid this conflict? Should we try to evangalize the Wink Toolkit to change their code and everyone who uses Wink to update to the fixed version? How widely used is it? (In particular, how widely used is .translate() rather than .winkTranslate()?) I don't mind changing the name, but it's unclear that there's a better name out there. It would be unfortunate to have to reserve the use of a name as generic as translate for a particular library. In any case we should definitely ask Wink to avoid unprefixed names. That's asking for trouble. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe sandbox attribute
On Mon, 26 Mar 2012, Boris Zbarsky wrote: On 3/26/12 3:13 PM, Mounir Lamouri wrote: I do not like [PutForwards=value] but I still believe DOMSettableTokenList is useful. I think the issue in this case is that the DOMSettableTokenList representation of the sandbox attribute, as specced, cannot distinguish between not sandboxed at all and sandboxed, with no loosening of any restrictions. That makes it very difficult to use, in my opinion. Very easy to shoot yourself in the foot. Changing it to a string doesn't affect that, though, does it? We can certainly add an attribute to DOMSettableTokenList (or rather, a descendant, for use specifically with iframe.sandbox) that does the same as .hasAttribute(), e.g.: iframe.sandbox.present ...or something, if that would help. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] script features
On Fri, 23 Mar 2012, Jonas Sicking wrote: The whole point of this feature is to enable the js-code inside a loaded script to use the .currentScript property in order to find the script element in the DOM which loaded it. Ah, ok. What's the use case for that? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, 19 Mar 2012, Jochen Eisinger wrote: I'd like to put forward a proposal for extending the modal prompts (alert/confirm/prompt) with an optional callback parameter. If the optional callback parameter is present, the javascript execution would resume immediately. The callback will be invoked when the dialog that doesn't need to be browser modal now, is closed. I wouldn't add such a callback to showModalDialog, as I think sites can use e.g. window.open instead. I've written up the proposal here: http://wiki.whatwg.org/wiki/Modal_prompts The motivation for this is that in a tabbed browser, modal dialogs are potentially disrupting the work flow of the user as they can't interact with any other web site as long as the modal dialog is displayed. Current browsers are having problems with the modal prompts: Chromium for example doesn't display a window created by showModalDialog in a modal way: http://crbug.com/16045 WebKit and Firefox don't suppress events while a modal dialog is running: https://bugs.webkit.org/show_bug.cgi?id=78240 and https://bugzilla.mozilla.org/show_bug.cgi?id=360872 Firefox displays modal prompts as tab-modal. However, it's possible to execute JavaScript in a tab that should be blocked by a modal prompt: https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from separate tabs can block each other: https://bugzilla.mozilla.org/show_bug.cgi?id=727801 Feedback on this proposal would be highly appreciated! Moving forward, I think the dialog element that we'll soon be adding is probably a better direction to go in. http://wiki.whatwg.org/wiki/Dialogs#Proposal -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Tue, 13 Mar 2012, Jonas Sicking wrote: Something that has come up a couple of times with content authors lately has been the desire to convert an ArrayBuffer (or part thereof) into a decoded string. Similarly being able to encode a string into an ArrayBuffer (or part thereof). Something as simple as DOMString decode(ArrayBufferView source, DOMString encoding); ArrayBufferView encode(DOMString source, DOMString encoding, [optional] ArrayBufferView destination); would go a very long way. The question is where to stick these functions. Internationalization doesn't have a obvious object we can hang functions off of (unlike, for example crypto), and the above names are much too generic to turn into global functions. Shouldn't this just be another ArrayBufferView type with special semantics, like Uint8ClampedArray? DOMStringArray or some such? And/or a getString()/setString() method pair on DataView? Incidentally I _strongly_ suggest we only support UTF-8 here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Tue, 13 Mar 2012, Jonas Sicking wrote: Unfortunately I suspect getting anything added on the String object will take a few years given that it's too late to get into ES6 (and in any case I suspect adding ArrayBuffer dependencies to ES6 would be controversial). We can just define it outside the ES spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Tue, 13 Mar 2012, Joshua Bell wrote: On Tue, Mar 13, 2012 at 4:10 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Mar 13, 2012 at 4:08 PM, Kenneth Russell k...@google.com wrote: Joshua Bell has been working on a string encoding and decoding API that supports the needed encodings, and which is separable from the core typed array API: http://wiki.whatwg.org/wiki/StringEncoding This is the direction I prefer. String encoding and decoding seems to be a complex enough problem that it should be expressed separately from the typed array spec itself. Some quick feedback: - [OmitConstructor] doesn't seem to be WebIDL - please don't allow UAs to implement other encodings. You should list the exact set of supported encodings and the exact labels that should be recognised as meaning those encodings, and disallow all others. Otherwise, we'll be in a never-ending game of reverse-engineering each others' lists of supported encodings and it'll keep growing. - What's the use case for supporting anything but UTF-8? - Having a mechanism that lets you encode the string and get a length separate from the mechanism that lets you encode the string and get the encoded string seems like it would encourage very inefficient code. Can we instead have a mechanism that returns both at once? Or is the idea that for some encodings getting the encoded length is much quicker than getting the actual string? - Seems weird that integers and strings would have such different APIs for doing the same thing. Why can't we handle them equivalently? As in: len = view.setString(strings[i], offset + Uint32Array.BYTES_PER_ELEMENT, UTF-8); view.setUint32(offset, len); offset += Uint32Array.BYTES_PER_ELEMENT + len; HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Tue, 13 Mar 2012, Joshua Bell wrote: WHATWG makes sense, I just hadn't gotten around to shopping for a home. (Administrivia: Is there need to propose a charter addition?) You're welcome to use the WHATWG list for this. Charters are pointless and there's no need to worry about them here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] API for encoding/decoding ArrayBuffers into text
On Tue, 13 Mar 2012, Joshua Bell wrote:
For both of the above: initially suggested use cases included parsing
data as esoteric as ID3 tags in MP3 files, where encoding unspecified
and is guessed at by decoders, and includes non-Unicode encodings. It
was suggested that the encoding sniffing capabilities of browsers be
leveraged. [...]
Whether we should restrict it as far as UTF-8 depends on whether we
envision this API only used for parsing/serializing newly defined data
formats, or whether there is consideration for interop with previously
existing formats data formats and code.
Seems reasonable. If we have specific use cases for non-UTF-8 encodings, I
agree we should support them; if that's the case, we should survey those
use cases to work out what the set of encodings we need is, and add just
those.
- Having a mechanism that lets you encode the string and get a length
separate from the mechanism that lets you encode the string and get the
encoded string seems like it would encourage very inefficient code. Can
we instead have a mechanism that returns both at once? Or is the idea
that for some encodings getting the encoded length is much quicker than
getting the actual string?
The use case was to compute the size necessary to allocate a single buffer
into which may be encoded multiple strings and other data, rather than
allocating multiple small buffers and then copying strings into a larger
buffer.
Ignoring the issue of invalid code points, the length calculations for
non-UTF-8 encodings are trivial. (And with the suggestion that UTF-16 not
be sanitized, that case is trivially 2x the JS string length.)
Yeah, but surely we'll mainly be doing stuff with UTF-8...
One option is to return an opaque object of the form:
interface EncodedString {
readonly attributes unsigned long length;
// internally has a copy of the encoded string
}
...and then have view.setString take this EncodedString object. At least
then you get it down to an extraneous copy, rather than an extraneous
encode. Still not ideal though.
- Seems weird that integers and strings would have such different APIs
for doing the same thing. Why can't we handle them equivalently? As in:
len = view.setString(strings[i],
offset + Uint32Array.BYTES_PER_ELEMENT,
UTF-8);
view.setUint32(offset, len);
offset += Uint32Array.BYTES_PER_ELEMENT + len;
Heh, that's where the discussion started, actually. We wanted to keep
the DataView interface simple, and potentially support encoding into
plain JS arrays and/or non-TypedArray support that appeared to be on the
horizon for JS.
I see where you're coming from, but I think we should look at the platform
as a whole, not just one API. It doesn't help the platform as a whole if
we just have the same features split across two interfaces, the complexity
is even slightly higher than just having one consistent API that does ints
and strings equivalently.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Validator.nu: Attribute role not allowed on element h2 at this point.
On Mon, 12 Mar 2012, Hugh Guiney wrote: Why not? I have this in an otherwise-valid HTML5 + SVG 1.1 + MathML 2.0 + RDFa Lite 1.1 document: hgroup h1Company Name/h1 h2 role=presentationTagline/h2 /hgroup Spec says: Authors must not set the ARIA�role�and�aria-*�attributes in a manner that conflicts with the semantics described in the following table, except that the�presentation�role may always be used. The validator is probably just not up to date. Note that that in this case the validator is probably right. If it's just presentational, why are you using h2? It doesn't seem presentational to me. I think you are incorrectly using role=presentational here. On Mon, 12 Mar 2012, Charles Pritchard wrote: Ignore the error, the HTML5 spec does not reflect implementations in this section about ARIA. The warning is not helpful to authors nor does it accurately describe the means in which ATs work with ARIA. Are you saying you think the spec is wrong here and we should not allow role=presentational? I tend to agree, but I'm not sure it's worth it to try and work out exactly when role=presentational is harmful (as in this case) and when it's not. On Mon, 12 Mar 2012, Charles Pritchard wrote: These should only be warnings, not errors. The language Authors must not is inappropriate. Warnings are generally not useful. Either something is fine and we should support it, or it's wrong and we should alert the author. I think must is very much the appropriate requirement level here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [media] startOffsetTime, also add startTime?
On Wed, 7 Mar 2012, Odin Hørthe Omdal wrote: startOffsetTime seem to leave people confused, I often have to explain it, and yesterday I read the spec[5] and old emails and got confused myself. It hasn't been implemented after almost 2 years. Can you elaborate on how it's confusing? I don't really understand. Having the UTC time of the clip you're getting would be very useful. But it'd be really nice to get the start of the non-normalized timestamp exposed to javascript for synchronizing out-of-band metadata with the live streamed media. What is the start of the non-normalized timestamp? Browsers are currently supposed to take the timestamp and normalize it to 0 for currentTime. Chromium currently does not do that; it starts at 3:15, if I join a streamed video that I started streaming 3 minutes, 15 seconds ago. If you start streaming at 3:15 (no date) into a stream that had a finite start at an implicit 0:00, then it is conforming (recommended as should, in fact) for the media's first frame to be at currentTime=195s. In fact if the media has a timestamp, browsers are explicitly urged (should) to only rebase it to 0 if the timeline has a negative component. If the media has a discontinuous timeline, the timeline used for the first part is required (must) to extend it to the rest of the resource, but it is still used as is. only if no timeline is present at all (e.g. an MJPEG stream) is the user agent supposed to use a zero origin for the timeline, and even then it's still only a should. I don't think using the UTC time as the sync point is very stable at the moment. It'd be a much quicker, stable, and easier win to get a startTime, timelineStartTime or timeSinceStart or similar that exposes the NON-normalized timestamp value at the start of the stream. So that, if you do startTime + currentTime you're able to get the actual timestamp that the stream is at, at that point. And in contrast with startOffsetTime this one won't ever change, so startTime + currentTime will always be continuously increasing. I don't understand what this is asking for. Can you give a concrete example with a specific media stream I can look at? The Date UTC which startOffsetTime would use, seems to be varying quite a bit. You need to know your streaming server and what it does in order to understand the result. Even different media from the same server might give different results if the streaming server implementation just reads the UTC time directly from the file. The information could be useful, but for more advanced uses. startOffsetTime is only useful when there's a date component. The only time I'm aware of that being available is for something like a cable TV DVR. Does any Web media format have a way to specify a date? Sean O'Halpin of BBC recently mentioned[2] some of the confusion: There seems to be some confusion here in how the HTML5 media elements specification is dealing with logical stream addressing versus physical stream addressing. The excerpt above talks about a user agent being able to seek to an earlier point than the first frame originally provided by the server but does not explain how this could possibly happen without communication back to the server, in which case we are effectively dealing with a request for a different physical resource. You'll definitely need communication with the server; even for just straight streaming without seeking, or for seeking forwards, you'll probably want client-to-server communication (e.g. for bandwidth management). Not sure what the difference is between a logical and physical resource in this case though. At the very least, the fact that the Firefox and Chrome teams came up with different interpretations shows that this part of the specification would benefit from clarification. The spec intentionally allows different behaviours with respect to how much of the stream the user is allowed to seek to. A browser could just make .seekable return a single empty range consisting of just the currentTime, for instance. I'm happy to change the spec on this point, but I don't understand what the problem is, so it's hard for me to make changes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [media] startOffsetTime, also add startTime?
streaming a Formula 1 race that starts at 17.00, I would not be surprised to see negative currentTime if I join the stream before the race starts. They are not, and shouldn't be. The spec doesn't actually disallow it, though it does discourage it. I could explicitly disallow a timeline with negative components. currentTime is always normalized to 0 - duration. I don't think the spec supports this assertion. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] di? Please?
On Sun, 4 Mar 2012, Hugh Guiney wrote: On Fri, Feb 3, 2012 at 3:22 PM, Ian Hickson i...@hixie.ch wrote: There are a number of places in HTML where it would be nice to be able to group things together -- just look at how often people stick divs in their pages for no purpose whatsoever other than styling. This shouldn't be necessary. It's a limitation of CSS. Then why is section in the spec? To make it easier to move subsections around without having to change all the h5s to h4s and so forth. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] di? Please?
On Sun, 4 Mar 2012, Hugh Guiney wrote: On Sun, Mar 4, 2012 at 5:07 PM, Ian Hickson i...@hixie.ch wrote: Then why is section in the spec? To make it easier to move subsections around without having to change all the h5s to h4s and so forth. That's it? That, and to give authors a common way to refer to sections instead of using div class=section with a huge variety of class names. So the fact that it provides explicit grouping and styling are unintentional side-effects? The only thing it adds to the grouping is the ability to have a subsection that is then followed by more content from the subsection's parent section. You couldn't do that with hx alone. However, for section that's more of a negative than a positive, really (it makes more sense for aside, nav, and article; section only allows it for consistency). I don't think I've come across a single person or article discussing section, in the time since its introduction, ever even mention rearranging subsections as a benefit at all, let alone the *primary* benefit. That's not even mentioned in the spec itself… The spec doesn't generally include design rationale. (If anyone would like to help maintain our rationale documentation, please let me know. We're always in need of volunteers there.) Furthermore, for h*, the spec provides examples of semantically equivalent document structures, one with sections and one without, concluding: Authors might prefer the former style for its terseness, or the latter style for its convenience in the face of heavy editing; which is besty [sic] is purely an issue of preferred authoring style. Its convenience in the face of heavy editing is what I am referring to above with respect to being able to move stuff around without changing h4s to h5s etc. (Fixed the typo, good catch.) If the decision to use section or not is purely an issue of preferred authoring style, what makes di any different? di doesn't exist. The ability to have multiple types of authoring style isn't the reason for section's existence. It's just a side-effect of now having two different ways to mark up sections. It's not actually a good thing in language design to have multiple ways to do something (despite what Perl might have us believe!). Why is in inappropriate to have a stopgap grouping element for dl while CSSWG works on a syntax for pseudo-grouping (if they even decide to do so), yet perfectly fine for sectioning content? section wasn't introduced as a stop-gap measure. There's no such thing as a stop-gap measure on the Web. We can't add something then remove it. Once we've added something, it's part of the platform, forever. That's why we have to be careful to only add things that make sense on the long term. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Addition of a setExtend(in DOMString extend) method to the CanvasGradient interface
On Tue, 19 Apr 2011, Jonathan Watt wrote: The extend mode of canvas gradients isn't under user control as it is in SVG. I'd like to propose adding a setExtend(in DOMString extend) method to the CanvasGradient interface, where the method would accept the arguments none, repeat, reflect and pad. These would be defined similarly to the values that the 'spreadMethod' attribute on SVG gradients accepts. http://www.w3.org/TR/SVG11/pservers.html#LinearGradientElementSpreadMethodAttribute Can't you just explicitly define the gradient across the entire range of coordinates that you plan to use it on? (i.e. is this just a convenience feature for something that's already possible?) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] including output in form submissions
On Tue, 13 Sep 2011, Michael Gratton wrote: HTML5 does not provide a means of submitting form content that is otherwise rendered as normal text, i.e. not as a form control. The use cases for this are the same as for the output element, but when it is also desirable for the result of a calculation to be sent to the server when the form is submitted. Currently, the only way to implement this is to maintain two copies of the value, one the child text of an output element (or something similar, for example a td or span) and once in the value of an input type=hidden element, using appropriate scripting to keep the two in sync. This is error prone and places an additional burden on the web page author. This can be remedied by allowing the value of output elements to be submitted. That is, include the output element in the submittable form-associated element category. I initially thought that this was precisely what the output element existed for - it was rather surprising when I tried using them but none of the values were appearing in the submission. You can work around this by just assigning the value to a hidden input when you assign it to the output control. But in general, I recommend against this. Anything that can be computed should be computed on the server to obtain the canonical value, otherwise you open yourself up to attackers sending you inconsistent data. On Wed, 14 Sep 2011, Michael Gratton wrote: [As an aside, it just occured to me that it would also be helpful if output supported the type attribute, for most of the same values as input now does in HTML5, for much the same reason as it makes sense for input.] It makes sense for input because it lets the browser know what interface to give to the user to let the user change the value... How does that make sense for output? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button
On Sat, 24 Sep 2011, Kaustubh Atrawalkar wrote: On 24-Sep-2011, at 12:24 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 23 Sep 2011, Kaustubh Atrawalkar wrote: If the form has submit button with display property as none, will that form should be implicitly submitted on pressing enter key? This works in Opera Firefox but does not work in IE Safari as of now. What is the expected behavior for this? The strict answer is that it's up to the browsers; the spec allows browsers to do whatever they think is appropriate per their platform's conventions. So both behaviours are compliant. But then this might result in website compliance issue. A website having username, password field with hidden submit button expecting to login on enter key using forms implicit submission will work on FF Opera but may not work on IE Safari. Yes. Similarly, some browsers might provide spelling checking, and others might not. Some might support tabbing from field to field, others might not. The thing is, if a platform does not have the concept of implicit submission, presumably the user wouldn't try to implicitly submit anything in the first place, so it doesn't matter if the browser does it or not. The guidelines in the spec do not say anything about the behaviour being different for elements that are display:none or otherwise hidden, though, so I don't see any reason to consider the visibility of a button in making the decision as to which button is the default. Second to your opinion, on the last line of the specs paragraph it says - If the form has no submit button, then the implicit submission mechanism must just submit the form element from the form element itself. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission This does not contradict what I wrote. It just says what to do if there IS an implicit submission mechanism, but there's no button at all. On Sat, 24 Sep 2011, Ryosuke Niwa wrote: WebKit's behavior is very confusing here. It does implicit submission in the following conditions: - One text fields - One text field with one visible submit button - Two text fields with one visible submit button - Two text fields with one visibility:hidden submit button - One text field with one display:none submit button However, it doesn't submit when we have: - Two text fields That's non-conforming currently. - Two text fields with one display:none submit button That's not really sensible, but it was technically within the spec's language. (You were allowed to not pick a default button if there was one to pick from but you didn't like it for some reason.) I've changed the spec to make this no longer allowed. The first button will now always be the default. Given that WebKit implicitly submits form even in the presence of a visible submit button or an invisible submit button (visibility: hidden, or display: none with exactly one text field), I don't see why we should avoid implicit submission only when there are multiple form controls and a display:none submit button. Agreed. On Sat, 24 Sep 2011, Ryosuke Niwa wrote: IE9 does implicit submission in the following conditions: - One text field - One text field with one visible submit button - One text field with one display:none submit button - Two text fields with one visible submit button It does not do implicit submissio in the following conditions: - Two text fields - Two text fields with one visibility:hidden submit button - Two text fields with one display:none submit button Basically, IE9 only does implicit submission when there is exactly one text field (you can have checkbox, hidden, etc...) or there is a visible button (i.e. not diplay: none nor visibility: hidden). If you submit with one text field and no button, then you are required to also submit with two text fields and no button. So this is non-conforming. Firefox 5 does implicit submission in the following conditions: - One text field - One text field with one visible submit button - One text field with one display:none submit button - Two text fields with one visible submit button - Two text fields with one visibility:hidden submit button - Two text fields with one display:none submit button It does not do implicit submissio in the following conditions: - Two text fields In summary, Firefox special cases one text field (can have checkbox, hidden, etc...) like MSIE and requires a submit button with more than two text fields regardless of presence of visibility: hidden or display: none. On Sun, 25 Sep 2011, Kaustubh Atrawalkar wrote: Opera - Does Implicit submission in following cases - * One text field * One text field with one visible submit button * One text field with one display:none submit button * Two text fields with one visible
Re: [whatwg] Focus remains on Hidden Element
On Sat, 8 Oct 2011, Kaustubh Atrawalkar wrote: In a form element, If a form input element has a focus and its then made hidden using style property display:none the focus still remains on the hidden element. According to specs ( http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus-management- 4th point) hidden input elements can not be focused. But there is still inconstancy in the browsers. The spec requires that focus be dropped in this case: When an element that is focused stops being a focusable element, or stops being focused without another element being explicitly focused in its stead, the user agent should synchronously run the focusing steps for the body element, if there is one; if there is not, then the user agent should synchronously run the unfocusing steps for the affected element only. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] focusability of visibility:hidden and display:none elements WAS: Autofocus readonly Input Elements
On Mon, 26 Sep 2011, Ojan Vafai wrote:
*8.3.2 Focus management*
An element is *focusable* if the user agent's default behavior allows it to
be focusable or if the element is specially focusable, but only if the
element is either being rendered or is a descendant of a canvas element that
represents embedded content.
As the test below shows, non-rendered divs with a tabindex are still
focusable in all browsers.
input elements whose type attribute are not in the Hidden state and that
are not disabled
It seems that all browsers also don't make visibility:hidden and
display:none input elements focusable.
The spec agrees:
An element is focusable if the user agent's default behavior allows it to
be focusable or if the element is specially focusable, but only if the
element is either being rendered or is a descendant of a canvas element
that represents embedded content.
I've tried to make this clearer.
DETAILS:
http://plexode.com/eval3/#ht=%3Cinput%20id%3Dtext%20type%3D%22%22%3E%3C%2Finput%3E%0A%3Cinput%20id%3Dhidden%20type%3D%22hidden%22%3E%3C%2Finput%3E%0A%3Cinput%20id%3Ddisabled%20disabled%3E%3C%2Finput%3E%0A%3Cinput%20id%3Dreadonly%20readonly%3E%3C%2Finput%3E%0A%3Cinput%20id%3Dvisiblity-hidden%20style%3D%22visibility%3Ahidden%22%3E%3C%2Finput%3E%0A%3Cinput%20id%3Ddisplay-none%20style%3D%22display%3Anone%22%3E%3C%2Finput%3E%0A%3Cdiv%20id%3Ddiv-hidden%20sytle%3D%22visibility%3Ahidden%22%20tabindex%3D1%3E%3C%2Finput%3E%0A%0A%3Cdiv%20id%3Dlogger%3E%3C%2Fdiv%3Eohh=1ohj=1jt=var%20result%20%3D%20''%3B%0A%0Afunction%20isFocusable(type)%20%7B%0A%20%20%20%20var%20element%20%3D%20document.getElementById(type)%3B%0A%20%20%20%20result%20%2B%3D%20type%20%2B%20'%20is'%3B%0A%20%20%20%20try%20%7B%0A%20%20%20%20%20%20%20%20element.focus()%3B%0A%20%20%20%20%20%20%20%20if%20(element%20!%3D%20document.activeElement)%0A%20%20%20%20%20%20%20%20%20%20%20%20result%20%2B%3D%20'%20not'%3B%0A%20%20%20%20%7D%20catch%20(e)%20%7B%0A%20%20%20%20%20%20result%20%2B%3D%20'%20not%20(error%20thrown)'%3B%0A%20%20%20%20%7D%0A%20%20%20%20result%20%2B%3D%20'%20focusable%3Cbr%3E'%3B%0A%7D%0A%0AisFocusable('text')%3B%0AisFocusable('hidden')%3B%0AisFocusable('disabled')%3B%0AisFocusable('readonly')%3B%0AisFocusable('visiblity-hidden')%3B%0AisFocusable('display-none')%3B%0AisFocusable('div-hidden')%3B%0A%0Adocument.getElementById('logger').innerHTML%20%2B%3D%20result%3Bojh=1ojj=1ms=100oth=0otj=0cex=1
Firefox 6, Chrome 16, IE9:
text is focusable
hidden is not focusable
disabled is not focusable
readonly is focusable
visiblity-hidden is not focusable
display-none is not focusable
div-hidden is focusable
div-display-none is focusable
The test above had a bug which made the divs not be properly hidden.
With that bug fixed, a visibility:hidden div and a display:none div also
come out as not focusable, as in the spec.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Specification of window.find()
On Wed, 20 Jul 2011, Tim Down wrote: On 6 January 2011 21:53, Ian Hickson i...@hixie.ch wrote: On Wed, 27 Oct 2010, benjamin.poul...@nokia.com wrote: I would like to suggest a change for the main HTML 5 specification: http://www.whatwg.org/specs/web-apps/current-work/ The problem I have is with the Window object specification (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ). It does not mention the method find() which can be found on most engines (e.g.: https://developer.mozilla.org/en/DOM/window.find ). It looks like IE doesn't implement this, so it's probably not strictly required for compat with the Web. What are the use cases for this feature? It's useful for custom search features. I've recommended it a few times on Stack Overflow for people wanting to highlight or somehow style all occurrences of a piece of text that may span nodes (it's this part that is the compelling feature). You can achieve the same using TextRange in IE. For example: http://stackoverflow.com/questions/5886858/full-text-search-in-html-ignoring-tags I think this is a valid use case. On a related note, I would like to see equivalents of some of the text-based methods in IE's TextRange make their way into Range, but that's a separate issue. So really it's not for use as a UI feature, but as a way to get Range objects for modifying the DOM. Interesting. On Wed, 20 Jul 2011, Aryeh Gregor wrote: However, the implementation here doesn't do what you'd want: it selects the text, destroying any existing selection. You can work around it by preserving and then restoring the selection somehow, but it's not ideal at all. It would make much more sense to have a function that returned a Range or list of Ranges. So I guess we have to make a decision for the platform here. Do we want: - To spec window.find() in all its historical glory, and have it implemented everywhere? - To spec a subset of window.find() that just does the use case described above, namely to destructively change the selection to a matching part of the DOM so that it can be manipulated by script? - To spec a new API that just returns matching ranges and then allows those ranges to be manipulated like the selection can be today? - To encourage authors to write a library that does this for them, and not bother to provide a dedicated API at all? Which would implementations that don't do the full window.find() today be willing to do? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Document's base URI should use the document's *current* address
On Wed, 20 Jul 2011, Justin Lebar wrote: The spec as written decides whether a link is a same-resource reference or not based on comparing the URLs to what you're calling the original address, not comparing it to the current address. See the navigation algorithm, step 7 /Fragment identifiers/. Maybe I'm misunderstanding, but this might not be the case in the history traversal algorithm. In history traversal, the URLs compared are those of the entries involved. However, clicking a link is primarily navigation, not session history traversal (though it can involve the latter). Step 6: If the specified entry has a URL whose fragment identifier differs from that of the current entry's when compared in a case-sensitive manner, and the two share the same Document object, then let hash changed be true. It's not clear to me what the current/specified entry's URL is, or where this is properly defined, but earlier, we say: Hm, yes, the spec doesn't quite clearly define the URL in all cases. Fixed. The current entry is usually an entry for the location of the Document. That's a non-normative statement. I've made it more explicitly so. and the document's location changes when we call push/replaceState. The current entry is whatever the algorithms last set the current entry to. I've made that clearer in the spec. As currently specified, we'll resolve #foo relative to the document's original URL; that is, clicking the link will take the user to page.html#foo, not page2.html#foo. But the intent of a link with href #foo is clearly to navigate within the current page, not to go somewhere else. Were you saying that this isn't the right interpretation of the spec? Because #foo is resolved relative to the document's base URI, which is the same as the document's original URI, so we decide that #foo is a same-document link? That's comforting, if it's true. :) When you click a link to #foo on a document whose current address is page2.html but whose document's address is page.html, then you go through these steps: - Start the Follow a hyperlink algorithm. - Resolve href relative to the a element. - This uses XML Base, with the fallback base url being the document's address, which is what you were calling the original URL. - This results in .../page.html#foo. - Navigate to that URL. - Step Fragment identifiers then compares this URL to the document's address (page.html, not page2.html), and finds a match. - Navigating to a fragment identifier is invoked and creates a new session history entry with the URL page.html#foo. - Traverse the history is then invoked. - It sets the document's current address to .../page.html#foo. - Scrolling happens. - The current entry's URL is ../page2.html and the specified entry's URL is .../page.html#foo so the fragids differ and hashchange fires. - The current entry becomes the new specified entry. Note that there are problems with what you describe: what if the new URL has a different path, and there are img elements whose URLs are relative, and after pushState() you clone one? Or what about relative links in the original markup? I don't think we can change the base URL on the fly, all kinds of problems could result. I agree there are problems with changing the base URI. But it seems much less intuitive for common use-cases not to change it. We can change my example above to use ?foo instead of #foo, and I think the same argument applies. Should a link with href ?foo always resolve relative to the document's original URI (unless the base is explicitly changed)? Yes, I'd say so. Otherwise cloning images would break. Similarly, if for some bizarre reason the page pushState's to a new directory, shouldn't all the links point relative to that new directory? That would break all existing images, stylesheets, scripts, etc, if their URLs are reused somehow. I kind of think this ship has sailed wrt implementations. Chrome and Firefox both have the same behavior in this respect. See http://people.mozilla.org/~jlebar/whatwg/test_pushstate_resolve.html (source included below, since I have a bad habit of deleting these test files right before someone else wants to look at them). Ian, how hard do you think it would be to spec changing the base and resolve the issues with that? Changing the base URL would be trivial, but I think it would cause all kinds of bad things and isn't what we should do. Consider: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1342 It doesn't make sense that the second image is broken. (For some reason in Firefox I get an exception. Not sure if I'm misusing the API or if it's a bug in Firefox.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Document's base URI should use the document's *current* address
On Wed, 15 Feb 2012, Justin Lebar wrote: Hm...maybe you're right. But then, how do we jive this with #foo and ?foo links, both of which resolve relative to the current URI in both Firefox and WebKit? We fix the implementations to match the spec. :-) - It sets the document's current address to .../page.html#foo. Well, this is pretty bad. document.location is the document's current address [1]. So clicking #foo changed document.location from page2.html to page.html#foo, which I certainly wouldn't expect (and does not match implementations). Seems to me we should change the implementations then. There isn't any fundamental difference between linking to #foo and linking to page.html#foo if the base URL is page.html, as far as I can tell. If the implementations can't change, then I'll change the spec, but it really seems bad to me that relative URLs will break depending on when they are resolved relative to pushState() changes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] a download feedback
On Fri, 22 Jul 2011, Glenn Maynard wrote: On Fri, Jul 22, 2011 at 2:58 AM, Ian Hickson i...@hixie.ch wrote: As Ian says above, if the user is savvy enough to right-click, the user is likely not going to find it difficult to give the file a name either. (But again, just because I'm able to do something by hand doesn't mean that I should be required to.) Well you're never _required_ to. The client can always use the server-provided name, even if it's download.cgi or something. Is there any reason to use CORS here at all? It seems like the simpler solution would be the following: - if the received resource has a Content-Disposition: attachment header that specifies a filename, use that. - otherwise, if the received resource has a Content-Disposition header that specifies a filename, and the resource is same-origin, use that filename. - otherwise, if the received resource is same-origin and the download= attribute specifies a filename, use that. - otherwise, if the received resource has a Content-Disposition: attachment header and the download= attribute specifies a filename, use the filename from the attribute. - otherwise, if the received resource is same-origin then derive a filename from the resource. - otherwise, either abort or alert the user that a file is being downloaded from a different origin and prompt for a filename. This doesn't allow cross-origin files to be linked to as both attachment and inline resources. Correct. That's intentional. If a victim server doesn't explicitly say that the resource is an attachment, then we don't want to allow a hostile server to trick the user into downloading the file at all. It's not so much that the server can't specify the filename, so much as you can't say that the file should be downloaded in the first place. It should show a warning and let the user select the filename. Your suggested workaround for the PDF case is to have two links, but in order to do that cross-origin you'd need to add Content-Disposition: attachment on the file, so that wouldn't work: they'd both become download links. You'd have to have two different URLs, one for inline embedding, and one for downloading, just as you do today without download=. This is intentional. You shouldn't be able to force a download cross-origin. Similarly, sites show an image inline and have a separate link to download it. For that link to use @download, C-D: attachment would have to be applied to the images, which is clearly unwanted. Only if the image is cross-origin. This breaks every case where I've wanted this functionality in the past. It doesn't make sense for @download to only work on files which are already marked as such by Content-Disposition. It works on same-origin files also, regardless of their C-D state. If you really want cross-origin @download to be opt-in, then use a separate header for it (Allow-Forced-Downloads: *); don't repurpose C-D like this. It's not repurposing, it's just using it for a case where before there would be a download but no given filename: now there can be a filename given in the markup. So, if a hosting service doesn't want to allow executable files, it won't show files as executable from their own download pages, which is what should matter as far as that site's trust is concerned. People using this mechanism to serve executable files from external links may be annoying, but it shouldn't cause trust issues. This implies the hosting service has to prevent pages from including download= attributes pointing to itself, of course. My point was the opposite; they don't need to do that. They're not providing the trojan-as-JPG from their own download pages, and if an external site links to a file and changes the extension to .EXE, then it's the external site that users should blame, not the download site. We're not trying to figure out who's to blame, we're trying to prevent there from being anyone to blame in the first place. On Fri, 22 Jul 2011, Alexey Proskuryakov wrote: On Tue, 19 Jul 2011, Alexey Proskuryakov wrote: I think that this attribute could be quite confusing, and it will likely become more confusing with time, as more platforms arise that have creative ways of presenting data to users. Could you elaborate on what confusion you are expecting here? Having rel=attachment and download be named so differently implies that the functionality is different. For example, I'm sure that many people will waste time trying to see what they can do with @download on an iPhone that they couldn't do before with Content-Disposition. I don't understand the relevance of rel=attachment (what is it?). I agree that people will waste time trying to work out whether iPhone supports download=, but the simplest solution to that (other than, you know, supporting it) would be just
Re: [whatwg] Why children of datalist elements are barred from constraint validation?
On Fri, 29 Jul 2011, Jonas Sicking wrote: On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 29 Jul 2011, Jonas Sicking wrote: On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 2 May 2011, Jonas Sicking wrote: On Mon, May 2, 2011 at 3:36 PM, Ian Hickson i...@hixie.ch wrote: select in a datalist is completely ignored for form submission. In fact, any form element at all in datalist is ignored for form submission. See the construct the form data set algorithm: http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set It's so that you can do things like: � input ... list=options � datalist id=options � � select ... � � � option.../option � � /select � � ...maybe other form controls here... � /datalist Basically everything in the datalist except the option elements is for fallback in legacy UAs and is ignored in new UAs. Couldn't this be accomplished using a few lines of javascript? Not when scripts are disabled, no. The number of cases when a site can use this solution to get an acceptable UI *and* care about supporting users with scripts disabled *and* is planning to roll out support within the timeframe when there's some support for HTML5 forms, but not enough to rely on it, is extremely small. That's possible. The entire Web Forms 2 feature set is designed with this kind of fallback in mind, though. My experience is that it's much more likely that people will use other solutions until there is wide enough browser support to reliably use it, and then use javascript as a fallback and not care about users with JS disabled. And that goes even if we add this feature or not. If that's the case, we should probably rethink the entire design of the WF2 features, because maybe there's better ways to do things. I'd be very interested to hear how we would have designed things differently under those constraints. Well for example we could have just done calendar instead of input type=date, indeed we could have used a format other than text/html... Looking specifically at datagrid's ability to fall back to select, I agree that it's not necessarily doing to be widely used, but given that it's so simple to support and provides such a clean way to do fallback, I really don't see the harm in supporting it. I haven't looked at datagrid yet, so I can't comment. I meant datalist, sorry. On Fri, 29 Jul 2011, Jonas Sicking wrote: Ah, well, then it definitely seems like we should get rid of this feature. The harm is definitely there in that it's adding a feature without solving any problem. I don't really understand what feature you mean. If you mean the fallback to select, I've actually wanted to use that on my own sites before, so I don't agree that it doesn't solve any problem. For what it's worth, I'm not even convinced there is a problem. The website can always let the select be submitted and ignore it on the server if it contains a empty value, and then make the first option in the select look something like option value=You can select a prefilled value here/option That's kind of ugly though. The spec's model is cleaner in this respect: the fallback select is just hidden entirely in modern UAs. I don't see why this would be a problem. On Sun, 31 Jul 2011, Jeremy Keith wrote: The way that datalist is currently designed (and implemented) is exemplary. The fact that (by design) it allows authors to nest a select element within it that shares the same option elements means that authors can safely begin to use this new feature. I've written more about it here: http://adactio.com/journal/4272/ I'm trying (and failing) to understand why Jonas wants this feature removed. On Mon, 1 Aug 2011, Jonas Sicking wrote: The reason is that I just don't think that sites will want to use it due to not being able to get the rendering or functionality that they want. I must admit that you were able to construct a somewhat decent UI using the current fallback mechanism, however I suspect that most sites will want to use a jQuery constructed UI which displays much nicer. In fact, I'd imagine that we'll see script libraries that implement the datalist UI without any browser support for browsers which don't have datalist support. I'll also note that even your demo doesn't require that the browser doesn't submit the select. So carrying around this behavior for all eternity, when it's going to be outdated in a few years once enough browsers support datalist, doesn't seem worth the small benefit that it gains us right now. The behaviour is rather minimal. It just cuts off a branch of the tree from contributing to the form. I really don't see why this is an undue burden, even if we have it for all eternity. On Tue, 2 Aug 2011, Henri
Re: [whatwg] Character-encoding-related threads
On Mon, 13 Feb 2012, Simon Pieters wrote: On Sat, 11 Feb 2012 00:44:22 +0100, Ian Hickson i...@hixie.ch wrote: On Wed, 7 Dec 2011, Henri Sivonen wrote: I believe I was implementing exactly what the spec said at the time I implemented that behavior of Validator.nu. I'm particularly convinced that I was following the spec, because I think it's not the optimal behavior. I think pages that don't declare their encoding should always be non-conforming even if they only contain ASCII bytes, because that way templates created by English-oriented (or lorem ipsum -oriented) authors would be caught as non-conforming before non-ASCII text gets filled into them later. Hixie disagreed. I think it puts an undue burden on authors who are just writing small files with only ASCII. 7-bit clean ASCII is still the second-most used encoding on the Web (after UTF-8), so I don't think it's a small thing. http://googleblog.blogspot.com/2012/02/unicode-over-60-percent-of-web.html I think this is like saying that requiring !DOCTYPE HTML is an undue burden on authors... It is. You may recall we tried really hard to make it shorter. At the end of the day, however, !DOCTYPE HTML is the best we could do. ...on authors who are just writing small files that don't use CSS or happen to not be affected by any quirk. If you have data showing that this would be as many documents as the ASCII-only documents, then it would be worth considering. In practice though I think it would be a very small group of pages, far fewer than the double-digit percentages using ASCII. In practice, authors who don't declare their encoding can silence the validator by using entities for their non-ASCII characters, but they will still get bitten by encoding problems as soon as they want to submit forms or resolve URLs with %-escaped stuff in the query component, and so forth, so it seems to me authors would be better off if we said that the encoding cruft is required cruft just like the doctype cruft. Hm, that's an interesting point. Can we make a list of features that rely on the character encoding and have the spec require an encoding if any of those are used? If the list is long or includes anything that it's unreasonable to expect will not be used in most Web pages, then we should remove this particular hole in the conformance criteria. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] document.write(\r): the spec doesn't say how to handle it.
On Mon, 19 Dec 2011, Henri Sivonen wrote: On Wed, Dec 14, 2011 at 2:00 AM, Ian Hickson i...@hixie.ch wrote: I can remove the text one at a time, if you like. Would that be satisfactory? Or I guess I could change the spec to say that the parser should process the characters, rather than the tokenizer, since really it's the whole shebang that needs to be involved (stream preprocessor and everything). Any opinions on what the right text is here? I'd like the CRLF preprocessing to be defined as an eager stateful operation so that there's one bit of state: last was CR. Then, input is handled as follows: If the input character is CR, set last was CR to true and emit LF. If the input character is LF and last was CR is true, don't emit anything and set last was CR to false. If the input character is LF and last was CR is is false, emit LF. Else set last was CR to false and emit the input character. I've done something like this (but simpler to spec). I've also done the second change I suggest above. On Thu, 3 Nov 2011, David Flanagan wrote: The spec seems pretty unambiguous that it operates on codepoints (though I implemented mine using 16-bit code units). §13.2.1: The input to the HTML parsing process consists of a stream of Unicode code points. Also §13.2.2.3 includes a list of codepoints beyond the BMP that are parse errors. And finally, the tests in http://code.google.com/p/html5lib/source/browse/testdata/tokenizer/unicodeCharsProblematic.test require unpaired surrogates to be converted to the U+FFFD replacement character. (Though my experience is that modifying my tokenizer to pass those tests causes other tests to fail, which makes me wonder whether unpaired surrogates are only supposed to be replaced in some but not all tokenizer states) This has changed a bit. In particular, Unicode code point is currently defined in a way that is (in theory) black-box indistinguishable from UTF-16 handling, but without making astral characters into second-class citizens. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 named entity Gt; and Lt;
On Wed, 14 Dec 2011, Mike Samuel wrote: The table in section 12.5 ( http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html ) says GT;U+0003E Gt;U+0226B≫ gt;U+0003E GT U+0003E gt U+0003E which I believe means that GT;, gt;,GT, and gt all encode but Gt; encodes U+226B MUCH GREATER-THAN. Correct. Similarly Lt;U+0226A≪ Correct. This is a potential source of confusion for naive HTML entity decoders fall-back to case-insensitive matching when there is no mapping for a given entity name. Such decoders are non-conforming. MathML already has other succinct mappings for U+226A (ll;) and U+226B (gg;). Could HTML5 avoid confusion by deprecating Lt; and Gt; in favor of ll; and gg; or remove them entirely? The mappings in the HTML standard are actually the MathML mappings. We literally use the same database they do to automatically generate the mapping in the spec. On Wed, 14 Dec 2011, Ilhan Y. wrote: By the way, can we have Unicode names (HTML names) for Mercury, Sun, Earth and other planets. They are used by many astronomers on the internet. The named character references used in HTML are just those provided to us by the MathML working group, so if you actually want a change here, I recommend contacting that group. In general though I doubt we will add more names. It's gotten rather out of hand. On Wed, 14 Dec 2011, Jukka K. Korpela wrote: After all, there is no rationale given for the inclusion of new “named character references,” so people might see the idea as asking authors to submit new proposals for every possible and impossible character. The rationale is compatibility with deployed MathML content. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] window.location aborting the parser and subsequent document.writes
On Thu, 5 Jan 2012, Henri Sivonen wrote: Consider https://bug98654.bugzilla.mozilla.org/attachment.cgi?id=77369 with the popup blocker disabled. Chrome, Opera and IE open a new window/tab and load the Mozilla front page into it. Firefox used to but doesn't anymore. As far as I can tell, Firefox behaves according to the spec: Setting window.location aborts the parser synchronously and the first subsequent document.write() then implies a call to document.open(), which aborts the navigation started by window.location. Per spec, aborting the parser doesn't cause document.write() to imply a call to document.open(). Specifically, it leaves the insertion point in a state that is defined, but with the parser no longer active, and discarding any future data added to it. Note that in this modified case http://hsivonen.iki.fi/test/moz/write-after-location.html (requires a click so that there's no need to adjust the popup blocker) the console says before and after but not later in Chrome and IE. That's consistent with the parser being aborted before the /head is document.write()n. The last \u003cscript never makes it into the parser, it just falls on the floor. Opera says before and after and then the opener script ends with a security error, because write is already a different-origin call, i.e. setting window.location has immediately made the document in the new window different-origin. That's definitely wrong, IMHO. Consider if the network responded with a redirect or something. How can you know what the origin is before the navigation is far further along? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The blockquote element spec vs common quoting practices
On Sun, 12 Feb 2012, Jukka K. Korpela wrote: 2012-02-12 2:13, Ian Hickson wrote: That's not to say that one day we won't provide an explicit way to mark up attribution for blockquotes in markup, just that the desired presentation isn't a relevant concern in doing so The relationship between a quotation and the indication of source is not presentational, and more than being a quotation is presentational. Agreed. The blockquote has been, and will be, rather pointless without markup for “credits” (indication of author and source, which are normally required by law). What's the use case, other than presentation? On Sun, 12 Feb 2012, Smylers wrote: Ian Hickson writes: On Thu, 14 Jul 2011, Kevin Marks wrote: There is another common pattern, seen in blogging a lot, of putting the citation at the top eg As cite class=vcarda href=http://www.gyford.com/phil/; class=url rel=acquaintance met colleagueabbr title=Phil Gyford class=fnPhil/abbr/a/cite wrote about the a href=http://www.gyford.com/phil/writing/2009/04/28/geocities.php;ugly and neglected fragments/a of Geocities:/p blockquote pGeoCities is an awful, ugly, decrepit mess. And this is why it will be sorely missed. It’s not only a fine example of the amateur web vernacular but much of it is an increasingly rare example of a emperiod/em web vernacular. GeoCities sites show what normal, non-designer, people will create if given the tools available around the turn of the millennium./p /blockquote ... the current markup handles it fine already (as you demonstrate above). Using cite like that isn't conforming, surely? You're right, I missed that cite was used instead of span there. The key part was the use of a paragrah giving attribution just before a blockquote being sufficient for practical purposes in blog comment cases such as the one Kevin was describing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The blockquote element spec vs common quoting practices
On Sun, 12 Feb 2012, Jukka K. Korpela wrote: 2012-02-12 19:54, Ian Hickson wrote: The blockquote has been, and will be, rather pointless without markup for “credits” (indication of author and source, which are normally required by law). What's the use case, other than presentation? What’s the use case for markup for quotations in general, other than presentation? The use case for most of the semantic markup is jsut easier authoring and maintenance, in particular for selectors in CSS. In the case of blockquote, we inherited it from HTML4 and so use cases weren't really a driving factor in the contemporary specification's development of the feature; it was more driven by consistency concerns. (Same as with, e.g., dfn, strong, and other semantic elements.) At the same level, “credits” can be used in editing and checking tools to verify that all quotations have credits (issuing warnings about those that don’t); in automatically generating a list of references; in an optional browsing mode where credits are hidden, with a button available for opening them; in finding out (even web-wide) which documents quote a certain document. Do any tools try to do any of this? If there are concrete use cases with software that is trying to address the use case and authors who want to use that software, then we should definitely look at the use cases. But we need to study the use cases and software, if that's the case. If we think that markup for quotations will not have much practical use, then it’s better to omit such markup altogether (and tell people to use whatever markup they like, maybe even blockquote if they prefer indentation). The practical use of moderately simplified maintenance is sufficient to justify keeping elements that are already deployed. I agree that if we didn't have the legacy here we probably wouldn't add blockquote or q, but that's water under the bridge. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The blockquote element spec vs common quoting practices
On Mon, 13 Feb 2012, Jukka K. Korpela wrote: 2012-02-12 23:25, Ian Hickson wrote: The use case for most of the semantic markup is just easier authoring and maintenance, in particular for selectors in CSS. If that’s the approach, and this reflects a consensus, shouldn’t this be explained in the introductory material (which is now rather limited and technical and does not really explain the goals and ideas)? Generally speaking I do not include rationales in the document, as that would basically double the length of the work. In the past we have had people work on rationale documents, e.g.: http://wiki.whatwg.org/wiki/Rationale If you (or anyone else) is interested in further maintaining this work, please don't hesitate to do so. The obvious meaning of “semantic” (and http://www.whatwg.org/specs/ speak about semantic markup without quotation marks) is that it is related to meaning, not ease of authoring. They're are not mutually exclusive. Documents that are marked up according to the meaning of the content tends to be easier to maintain, especially in the face of changing desires with respect to the presentation. The concept of CSS and especially alternative style sheets is predicated on the document markup being rich enough that specific parts, e.g. headings, paragraphs, sections, sometimes even quotes, can be directly selected and styled. If you don’t expect semantic differences as such make any difference, then why introduce semantic markup at all? The basis of HTML on semantic markup far predates this effort. Surely it would be easier to author if you can introduce your own tags as you go, designing a tag set that suits a particular page, site, or application. Authors are of course able to do this using just div class= or even just XML, but in general document maintenance, especially across multiple authors over time, is significantly helped by the use of a common vocabulary. If the idea is that in collaborative environments, it is easier to work when everyone uses the same tags, then it’s really about setting design and coding practices. It would be something rather orthogonal to all other aspects of HTML. Yes. In the case of blockquote, we inherited it from HTML4 and so use cases weren't really a driving factor in the contemporary specification's development of the feature; it was more driven by consistency concerns. Consistency with existing practice would be achieved by describing the default rendering in browsers. That's certainly part of the work required of us (and it is done). There’s little reason to aim at describing the semantics if it’s not really expected to be relevant The semantics are definitely relevant. As I said in my last e-mail, they are what helps ease authoring and maintenance. especially since we know that very often, existing pages (and existing authoring software) uses blockquote just for indentation. Can you elaborate on your source for this? Data is always welcome. I'm not aware of a study that shows this one way or the other. Designers and people who set coding standards can specify how they want blockquote to be used If authors want to use text/html, and the HTML lexicon, but with different meanings, they are naturally able to do so by just writing their own spec that defines the language as they desire. There's nothing magical about the HTML standard; it's only useful because people agree amongst themselves to use it as their common definition of the vocabulary. (Same as with, e.g., dfn, strong, and other semantic elements.) They, too, as well as b and u, have been modified quite a lot dfn and strong haven't really been modified, merely clarified. b and u have been repurposed. with elaborated explanations about their meanings, causing both confusion and argumentation. I think overall the confusion and argumentation is significantly less for all these elements than it ever was in the HTML4 days. :-) It would be so much simpler, and it would give the same authoring and maintenance ease, to describe just how browsers render them by default. I think this rather misses the point. It's not the common default rendering that makes authoring with these elements easy. The default rendering is almost always overridden anyway. It's the common definition of the elements' meanings that helps ease authoring and maintenance. An author can join a project, and can immediately use h1 and know that whatever the page's styles are, they'll give h1 the same heading style as the main heading on all the other pages of the site. A blog author using a default theme can use blockquote to indicate when she quotes from another source, and then change to another theme with some confidence that the new styles will also treat blockquote in that way. If we only defined default renderings, there would be no way to be sure that that would happen. Many of the new
Re: [whatwg] The blockquote element spec vs common quoting practices
think that the non-visible-effect-URL attributes on elements should be considered an anti-pattern, evidenced by the fact that they (cite, longdesc, profile etc.) have all failed to get any meaningful uptake among web developers). Agreed. The only reason I haven't dropped cite= is that it doesn't cause any harm (unlike, say, longdesc=). label for=input-id is a known working and in use pattern. It has an effect. Thus I feel much more confident advocating use of the parallel: cite for=quote-id What effect would it have? You just pointed out that a feature with no effect is an antipattern. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Character-encoding-related threads
in the range 0x80-0xFF, which are not defined in ASCII). HTML defines both. On Wed, 7 Dec 2011, Henri Sivonen wrote: I believe I was implementing exactly what the spec said at the time I implemented that behavior of Validator.nu. I'm particularly convinced that I was following the spec, because I think it's not the optimal behavior. I think pages that don't declare their encoding should always be non-conforming even if they only contain ASCII bytes, because that way templates created by English-oriented (or lorem ipsum -oriented) authors would be caught as non-conforming before non-ASCII text gets filled into them later. Hixie disagreed. I think it puts an undue burden on authors who are just writing small files with only ASCII. 7-bit clean ASCII is still the second-most used encoding on the Web (after UTF-8), so I don't think it's a small thing. http://googleblog.blogspot.com/2012/02/unicode-over-60-percent-of-web.html On Mon, 19 Dec 2011, Henri Sivonen wrote: Hmm. The HTML spec isn't too clear about when alias resolution happens, to I (incorrectly, I now think) mapped only UTF-16, UTF-16BE and UTF-16LE (ASCII-case-insensitive) to UTF-8 in meta without considering aliases at that point. Hixie, was alias resolution supposed to happen first? In Firefox, alias resolution happen after, so meta charset=iso-10646-ucs-2 is ignored per the non-ASCII superset rule. Assuming you mean for cases where the spec says things like If encoding is a UTF-16 encoding, then change the value of encoding to UTF-8, then any alias of UTF-16, UTF-16LE, and UTF-16BE (there aren't any registered currently, but Unicode might need to be one) would be considered a match. It doesn't matter if I refer to you as Henri or hsivonen, in both cases we're talking about the same person. There's also the overrides. The way the spec is written, the Character encoding overrides are not aliases (at least not in the character encoding registry sense). The spec just requires that when you would instantiate a Foo decoder or encoder, you instead use a Bar one. Currently, iso-10646-ucs-2 is neither an alias for UTF-16 nor an encoding that is overridden in any way. It's its own encoding. Anne's Encoding draft may make overrides into aliases. In practice I do not believe this will cause any normative change to the behaviour since the only time that character encoding identities are compared (as opposed being used, where the overrides kick in) is for UTF-8 and UTF-16 encodings, and those don't have overrides (and hopefully never will). I hope the above is clear. Let me know if you think the spec is vague on the matter. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Using footer in blockquote for attribution
On Fri, 1 Jul 2011, Oli Studholme wrote: Over at http://html5doctor.com we�ve been using this pattern when quoting e.g. from the HTML5 spec: blockquote p[block quote]/p footer� citea href=�[title of work]/a/cite/footer /blockquote I wrote about our use of blockquote and footer in http://html5doctor.com/blockquote-q-cite/ recently, which lead to http://www.w3.org/Bugs/Public/show_bug.cgi?id=13082. To recap: Footer definition: �The footer element represents a footer for its nearest ancestor sectioning content or sectioning root element. A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like.� Blockquote definition: �The blockquote element represents a section that is quoted from another source. Content inside a blockquote must be quoted from another source, whose address, if it has one, may be cited in the cite attribute.� Simon felt that �Content inside a blockquote must be quoted from another source� excludes footer. On what basis? However the footer definition reads to me that footer is basically metadata *about* content (the non-footer or -header content of the sectioning or sectioning root element). I�m happy to propose some reasons for allowing this, but to start with does blockquote�s definition beat footer�s definition? Or, is footer considered content as far as the blockquote definition is concerned? Content in a blockquote is quoted. This includes any footers in it. For example, a page might say: article h1My Opinion/h1 pBla bla bla./p pBla bla bla./p pAnd furthermore, I think fish are friends, not food./p footer pFred is a shark./p /footer /article Another page might then quote that page: pBut the best part is the end, where Fred writes:/p blockquote cite=http://fred.example.net/blog/my-opinion; pAnd furthermore, I think fish are friends, not food./p footer pFred is a shark./p /footer /blockquote pNotice the footer saying that he's a shark! Sharks emlike/em to eat fish, surely./p It's not clear to me why or how the spec is ambiguous here. I've not added this specific example to the spec, but I've added unambiguous requirements regarding attribution. On Fri, 1 Jul 2011, Simon Pieters wrote: Indeed since it's a conformance requirement, in valid documents the content inside blockquote is quoted from another source. If the spec were to allow attribution inside blockquote, the above conformance requirement would need to be changed to allow it. Indeed. On Tue, 5 Jul 2011, Jukka K. Korpela wrote: I was pretty sure that I had seen an example where a blockquote element contained an attribution in a footer. Alas, the “living standard” does not seem to have a version history where I could conveniently check this out. You can see all versions of the spec ever published using the Subversion repository. See the spec header for tools for accessing it. Admittedly, there is some logic in requiring that the content of blockquote be quoted from an external source and nothing more. I wonder whether this disallows common constructs like “[foo]” to indicate that “foo” has been added for clarification and is not present in the source. I've addressed this. Anyway, having a blockquote element but no markup for attribution is very illogical. Indeed. We may fix this in due course. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should events be paused on detached iframes?
On Tue, 7 Feb 2012, Boris Zbarsky wrote: On 2/7/12 7:16 PM, Ian Hickson wrote: All of the above seem consistent with what the spec requires. Firefox actually seems to have a slight bug, which is that the event loop keeps pumping in the original page, but that seems like a separate issue. Here's the test case you describe above: http://damowmow.com/playground/tests/alert/001.html OK, then I don't understand something. You said: It should put it up in the context of the top-level browsing context of the script that led to that point (the first script). This is the same as if someone in one tab calls another tab's script and that script calls alert(). I assume you meant entry script, but maybe that was a bad assumption? There is no first script anywhere in the spec. First script was the old name for what is now entry script. In any case, in my testcase the entry script is the one running in test1.html, but the alert is being associated with test2.html. In general, I would expect that alerts are associated with the window that was the |this| for the alert call I shouldn't give you answers from memory! The spec doesn't say where the dialog goes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should events be paused on detached iframes?
On Wed, 8 Feb 2012, Boris Zbarsky wrote: On 2/8/12 3:20 PM, Ian Hickson wrote: In any case, in my testcase the entry script is the one running in test1.html, but the alert is being associated with test2.html. In general, I would expect that alerts are associated with the window that was the |this| for the alert call I shouldn't give you answers from memory! The spec doesn't say where the dialog goes. OK, good. But that brings us back to the original question in this thread, no? Unless the answer is just that the spec doesn't define it? Should events be paused on detached iframes? Or another question? (Sorry, I've lost the context here.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should events be paused on detached iframes?
On Wed, 8 Feb 2012, Boris Zbarsky wrote: On 2/8/12 3:50 PM, Ian Hickson wrote: Should events be paused on detached iframes? Or another question? (Sorry, I've lost the context here.) The thread is discontinuous in the archives (why?) Mailman archives suck. I found the thread in a more usable form here: http://old.nabble.com/Should-events-be-paused-on-detached-iframes--to29526129.html#a29526129 but I think the relevant part was: It's possible to switch these relevant checks to walk the ownerDocument chain instead, say. Then we need to audit all the callsites to make sure this makes sense at them and figure out what to do for the ones where it doesn't. (For example, should window.alert on the window of an iframe not in the DOM put up a dialog in a tab based on the ownerDocument of the iframe? Or not put one up at all?) There are quite a few APIs that need to be thus audited if this invariant is changed. My overall response is still the same: I'm happy to consider specific cases. As far as I'm aware, the spec doesn't have any privilege escalation bugs of this nature. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] title/meta elements outside of head
On Thu, 19 Jan 2012, Michael Day wrote: Currently the spec seems to indicate that title and meta elements found in the body will stay where they are and not be added to the head. However, if these elements occur after the head and before the body then they will be added to the head. Is this intentional? Sample document #1: html head /head body titleThis will stay in the body/title Sample document #2: html head /head titleThis will be moved to the head/title Sample document #3: html head abc titleNow we are in the body, where this will stay/title What is the reason why title/meta elements are not always moved to the head, regardless of where they appear? On Thu, 19 Jan 2012, Henri Sivonen wrote: They didn't need to be for compatibility, so we went with less magic. Also, being able to use meta and link as descendants of body is useful for Microdata and RDFa Lite without having to mint new void elements. Henri is correct. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Decimal comma in numeric input
On Thu, 19 Jan 2012, John Tamplin wrote: [...] a user types 1,575 in a field. Is that interpreted as a value between 1 and 2 or between 1000 and 2000? [...] That's entirely up to the UA. On Thu, 19 Jan 2012, Bronislav Klu�~Mka wrote: This should depend on selected locale, is coma thousands or decimal separator? Browser should follow such settings and display value accordingly, but value MUST be sent to server according to 1 set of rules, regardless of anything else (e.g. no thousands separator and full stop as decimal separator). No browser locale, no server locale... one set of rules. Consider JavaScript here... regardless of displayed value, you always get Number type out of it (not string like 15.123,55 but 15123.55) So it is just display here, but spec should explain the difference between display value and underlying data. Correct. On Fri, 20 Jan 2012, Jukka K. Korpela wrote: 2012-01-20 1:19, David Singer wrote: What the user enters and sees on screen is a presentational/locale issue Which one? That's defined by the UA. (The spec has some suggestions.) On Fri, 20 Jan 2012, Cameron Heavon-Jones wrote: The lang attribute is the structural declaration of the content's localization, be it prose or data values. Technically it just sets the language, not the localisation. I expect we will in due course add an attribute to explicitly set the locale of the content in the page. How it's rendered would then be controlled by new features in CSS (e.g. the page locale could be British, and the presentation could be American, which would mean dates would have their day and month fields flipped over). Similarly, the presentation layer ultimately controls the widgets, including how they work and what input formats they expect, e.g. through XBL or whatever replaces it. This is all pie in the sky, though, it doesn't exist today. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, 10 Jan 2012, Adam Barth wrote: On Tue, Jan 10, 2012 at 2:35 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 14 Jun 2011, Adam Barth wrote: On Tue, Jun 14, 2011 at 2:03 PM, Alexey Proskuryakov a...@webkit.org wrote: 28.02.2011, в 21:38, Ojan Vafai написал(а): FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 What is the big difference between alerts from unload and alerts in general? Alerts are not particularly useful for anything besides debugging, and pagehide/unload handlers is a place where they I've found them particularly useful for debugging. Do we have at least anecdotal evidence that many sites are showing alerts from unload? When I'm seeing a site that tries to prevent me from leaving it, it's always by returning a string from onbeforeunload. I believe the motivation is to be able to close tabs quickly. If a tab doesn't register for any unload / beforeunload events, the tab can be kill instantly. If the site registers for unload but not beforeunload, then, today, we need to wait for JavaScript to execute before closing the tab. Without the ability to trigger alert and friends during unload, we can hide the tab instantly and unload it in the background. We have lots of stats for how many tabs would benefit from this optimization and how much time would be saved. It's surprisingly large. Any news on this? If Chrome was able to do this, it would be worth putting in the spec to give cover to other browsers interested in the same potential performance improvement. Ojan probably has more concrete data. I think we got one or two complaints, but no major problems. On Tue, 10 Jan 2012, Ojan Vafai wrote: The only complaint I'm aware of is in http://crbug.com/97206. The bug comments are confusing. The primary issue there is WebKit not firing beforeunload/unload from frames in some cases, but there is one comment about code that calls confirm from unload handlers followed by a sync XHR to save data that now breaks. I've specced this (it's optional for now). I didn't check how closely what I specced matches Chrome. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Idea: pseudo-classes :valid and :invalid for whole form?
On Wed, 11 Jan 2012, Mounir Lamouri wrote:
On 01/11/2012 01:05 AM, Ian Hickson wrote:
On Tue, 14 Jun 2011, Rafa�~B Mi�~Becki wrote:
We already have required attribute and :valid plus :invalid classes,
which are nice. However some may want to display additional warning
when form wasn't filled correctly. Just some single warning, not
specific field-related. Could you consider adding form element class
for such a purpose?
Example:
p id=errYou've to fill all required fields/p
form:invalid #err {
display: block;
}
On Wed, 15 Jun 2011, Boris Zbarsky wrote:
Yep. I think we should do it.
I've added this to the spec.
Wouldn't be interesting to have the same thing for fieldset?
Are there sites that indicate validity of sections of the form in this way?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] should we add beforeload/afterload events to the web platform?
struggle to think of good web-facing use cases for this, though. In any event I think that beforeload as it exists today is a bad API for the web and hope that we can stop exposing it to the web in WebKit (although I suspect it'll stick around for extension contexts, which is more acceptable in my view). I couldn't agree more with the above. On Tue, 10 Jan 2012, Adam Barth wrote: Some web sites use beforeload to monitor for mixed content vulnerabilities. In some cases, they block the load, and in other cases they allow it (e.g., because they're working to clean up their mixed content bugs). On Tue, 10 Jan 2012, Boris Zbarsky wrote: Do they really need to block the load, or block processing of the response? For the mixed-content case, it seems like blocking processing of the response is enough (and that furthermore only the URI is needed, not the actual element, to detect mixed-content cases). On Tue, 10 Jan 2012, Adam Barth wrote: The actual element turns out to be useful tracking down and fixing these issues, at least in complicated web sites. For example, suppose your web application contains widgets written by separate teams and you want to block mixed content requests in some, but not all, of these widgets. To be clear, I'm not the biggest fan of beforeload because dispatching synchronous events during loading is pretty tricky. It took us a while to get the crashes out of the WebKit implementation. They are reasonably popular, however. On Tue, 10 Jan 2012, Boris Zbarsky wrote: OK. I have no serious problem with a beforeprocess event that fires before processing the response, esp. if processing is defined in a page-visible way (so e.g. you could still compile a script in the background before firing beforeprocess; you just couldn't run it). I don't have an objection to adding a cancelable bubbling event that fires synchronously as part of the execute a script block algorithm, between the current steps 1 and 2 of if the load was successful, which gets the URL of the script, targetted at the script, which if canceled cancels the execution of the script. Does any browser have an event like that already? If not, any opinions on an event name? script onbeforerun=? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] di? Please?
On Tue, 10 Jan 2012, Hugh Guiney wrote:
As I understand it, the main reason for rejecting di was that it
solves a problem that is allegedly CSS's job, but as an author who uses
dls quite extensively, adding a grouping element would really make my
life a lot easier.
There are a number of places in HTML where it would be nice to be able to
group things together -- just look at how often people stick divs in
their pages for no purpose whatsoever other than styling.
This shouldn't be necessary. It's a limitation of CSS.
The right solution is for CSS to provide some pseudo-element or other
mechanism that introduces an anonymous container into the rendering tree
that wraps the elements you want to wrap. For example, with the square
brackets representing the anonymous boxes:
dl
[dtdd]
[dtdd]
/dl
dl::group(dt...dd) { border: solid; }
header
pa href=/Home/a
[
h1The Blog/h1
p class=bylineOur blog away from home
]
p class=copyrightBla bla
/header
header::group(h1...p.byline) { border: solid; }
This isn't a formal proposal, but you get the idea. If we solve this
problem, the need for di completely goes away, but more importantly, so
does the need for a huge number of divs.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Fri, 3 Feb 2012, Boris Zbarsky wrote: On 2/3/12 3:07 PM, Ian Hickson wrote: OK. I have no serious problem with a beforeprocess event that fires before processing the response, esp. if processing is defined in a page-visible way (so e.g. you could still compile a script in the background before firing beforeprocess; you just couldn't run it). I don't have an objection to adding a cancelable bubbling event that fires synchronously as part of the execute a script block algorithm, between the current steps 1 and 2 of if the load was successful, which gets the URL of the script, targetted at the script, which if canceled cancels the execution of the script. Does any browser have an event like that already? If not, any opinions on an event name?script onbeforerun=? Gecko has a beforescriptexecute event. It's a simple event targeted at the element; there's no reason to include the URI, since that can be gotten off the element. I believe calling preventDefault() on it will prevent the script from executing. Ok, I've added that to the spec. I also believe that we have proposed this for standardization in the past, though it seems to have fallen through the cracks a bit... I couldn't find any mention of it in the WHATWG archives or Bugzilla, though I did find an e-mail from sicking saying he'd proposed it to the WHATWG list. :-( But note that this is script-specific; I believe that content-blocker use cases would want this for images, stylesheets, etc. As noted in the previous e-mail, it's not clear that the content-blocker use cases are valid. The use case that is compelling for beforescriptexecute is regarding sites who are trying to address mixed content vulnerabilities progressively and need to closer control over external script execution. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] the impact of select.value behavior clearing current selection prior to setting the new selection
On Thu, 2 Feb 2012, Cameron McCormack wrote: Ian Hickson: It's my understanding that what you describe as what browsers do is also what the specs require. The attribute is defined as being of type long, so if I'm not misreading the Web IDL spec, the browser will try to convert the null or string value to a number (and fail) long before the HTML spec's prose is relevant. For the long type, null and strings like junk will get converted to 0. http://dev.w3.org/2006/webapi/WebIDL/#es-long Turns out this is actually what specs do, too! I didn't test the null case before sending my last reply, but having now tested it, it seems Firefox, Webkit, IE10 (thanks to Aryeh for testing that), and Opera all do what the specs say to do here. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1321 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] On using abbr with no title and screen readers
On Tue, 20 Dec 2011, Jorge wrote: I am trying to make myself clear on how and when to use abbr, if at all, specifically when it does not need expansion and hence does not a title attribute. If you don't need expansion, then the only reason to use abbr is to have a styling hook (e.g. if you want to make your abbreviations small caps, or want to change how a speech browser reads out the abbreviation -- both of these would be controlled either via CSS, or by the browsers' default or user settings, or in heuristics similar to those you described). I haven't updated the spec on this matter; please let me know if you think the spec could be clarified in a helpful way here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A few questions on HTML5
On Tue, 3 Jan 2012, Mani wrote: I had a few quick questions on HTML5 (I have been looking at it for about a month now, and I am fascinated by the possibilities). 1. I believe HTML5 will use no DTD, is that right? So there will be rules for HTML5 processors (browsers) that they should follow? Assuming you mean for parsing purposes, the rules to follow are: http://whatwg.org/html#parsing Can you also comment as to why?? (I believe the reason is to support not well-formed HTML and still not contradict other standards.??) HTML is no longer based on SGML, so it's no longer relevant. 2. Will XHTML5 have a DTD, because XHTML5 must be well-formed? You can provide DTDs if you like, but there are no formal ones. DTDs aren't required to define parsing rules for XML, and are insufficient to describe all the conformance requirements that validators are required to check for. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] the impact of select.value behavior clearing current selection prior to setting the new selection
On Tue, 3 Jan 2012, Jon Lee wrote: A long while ago there was a clarification made to the html5 spec about how setting selectedIndex and value clears out the selectedness of all options prior to setting the selection. As of this writing, Safari, Chrome, Opera, and Firefox leave the selection alone if the code sets value to null or a string that does not match any of the existing options. I was wondering if anyone had any insight on impact for existing websites with this new behavior. It's my understanding that what you describe as what browsers do is also what the specs require. The attribute is defined as being of type long, so if I'm not misreading the Web IDL spec, the browser will try to convert the null or string value to a number (and fail) long before the HTML spec's prose is relevant. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
