Re: [whatwg] suggestin a minor addion to the DOM
On Thu, 28 Jun 2012, Andri S�var Sigr�ksson wrote: > > suggestion > > Boolean value > > implemented as Window.nobackspace or Navigator.nobackspace > > if set to true the browser would not accept the key press on backspace > as a signal to go to the previous page > > yes i know there is a other way to do this but i find it unelegant On Thu, 28 Jun 2012, Bjoern Hoehrmann wrote: > > Why would users want that? On Thu, 28 Jun 2012, Chaals McCathieNevile wrote: > > Generally it isn't a very nice thing for users not to go back. It's a > pretty fundamental part of the way we navigate the web. Redirecting the > back button somewhere else because of a strange forward navigation path > might happen, but breaking the general expectation isn't usually a good > idea. > > Also, the fact that we have an inelegant way of doing something isn't > necessarily an argument to make it easier. If it's a really common thing > to do, then it makes sense to simplify it. But if it is a weird edge > case, then duplicating stuff is a good way to let bugs creep into > implementations, which come at the expense of doing something more > useful... On Thu, 28 Jun 2012, Tab Atkins Jr. wrote: > > You may be misreading this - it's about turning off the "backspace means > go back in history" functionality that some browsers have in some > circumstances. It's not trying to shut down back navigation generally. > > I can easily see an editting-heavy page wanting to turn off this > behavior, as when I was still a FF user, I'd occasionally get accidental > navigations because I didn't notice that an input or textarea had lost > focus. On Thu, 28 Jun 2012, Chaals McCathieNevile wrote: > > Ah. In that case I can see the use case. But I don't think this is such > an elegant approach either, because the underlying problem is not just a > specific key but the general behaviour of the browser when you are > dealing with interactive components (editing is one). This is related to > the use cases for the aria role "application"... I haven't added this, but I agree that it's an issue. Really what is needed is more a "keyboard capture" mode where normal keyboard shortcuts get disabled so that the application can handle them. However, it's not clear exactly which you would want. Sometimes you might e.g. want left/up/right/down to no longer scroll the page, but other times you might still want it to scroll an overflowing div. You might want the space bar to not scroll down but instead to fire a weapon in a game, but if the app scrolls (e.g. as GMail does) maybe you still want it to page down. I don't know what a good solution is. The current solution is to just catch the keystrokes you care about and cancel them... that might just be the way to go for now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Change description of em element
On Wed, 27 Jun 2012, Joseph Mansfield wrote: > > The current semantic meaning of the em element may be confused with that > of the strong element. The specification states that the em element > increases the level of emphasis. There are, however, two definitions of > the word "emphasis": > > 1. Importance, value, or prominence given to something. > 2. Stress laid on a word or words to indicate special meaning or >particular importance. > > While the specification does specify that the em element represents > "stress emphasis" - the form of emphasis that changes the meaning of a > sentence - the frequent use of the word "emphasis" alone may imply > importance. However, the strong element is responsible for importance. > Take the given example: > > Cats are cute animals. > > The cats are not important - they are stressed. Stress changes the > meaning of the sentence, while importance does not. > > To make this clearer, I suggest two options for changing section 4.6.2: > > 1. Keep the "stress emphasis" from the first sentence and replace all >other occurences of "emphasis" with "stress emphasis". > 2. Replace occurences of "stress emphasis" and "emphasis" with simply >"stress". This, however, loses the attachment to the element name. I've tried to make this clearer in the spec. Let me know if there's any cases that are still confusing in this manner. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for HTML5: Virtual Tours
On Mon, 25 Jun 2012, Jes�s Ruiz Garc�a wrote: > > So far, all the more powerful virtual tours I've seen, are made in Flash. > Usually, these tours are created with the following applications: > *Easypano Virtual Tour Software*, *3DVista*, *Flashificator*, *Autopano Tour > * and some others. > > An example of Easypano virtual tour: > http://www.vitaldent.com/nuestras_clinicas.jsp > > Other examples using 3DVista: > http://www.3dvista.com/virtual-tours-samples.htm > > I've been reviewing whether some library is being developed to support the > creation of these applications on HTML5. I found a project called > Pannellum, which uses WebGL: > http://www.mpetroff.net/archives/2012/05/28/introducing-pannellum/ > For now though it works properly on Chrome, but isn't powerful or > beautiful, as are the tours developed with Flash applications. > > My proposal is to give more support to this type of works. To add support for these, we need to know what they need. What is the Web platform missing that will help with such virtual tours? > We could create a new tag called "tour" or something similar. If video > and audio have own tag, also a tour could be differentiated from the > other elements of the website. What would such an element do? On Fri, 29 Jun 2012, Jes�s Ruiz Garc�a wrote: > > Surely with Canvas (WebGL) can be created perfectly virtuals tours. I'll > try to do some testing and I will comment on results. I believe Google Maps can be made to use WebGL for its street view tours. > By the way, what label should be used to indicate this type of media?. > Canvas? I'm not sure I understand the question. Can you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for HTML5: Motion sensing input device (Kinect, SoftKinetic, Asus Xtion)
On Mon, 25 Jun 2012, Jes�s Ruiz Garc�a wrote: > > My proposal for HTML5 is to make it functional with Kinect, SoftKinetic, > Asus Xtion, and similar devices to interact with the web. On Mon, 25 Jun 2012, Tab Atkins Jr. wrote: > > The ability to capture sound and video from the user's devices and > manipulate it in the page is already being exposed by the getUserMedia > function. Theoretically, a Kinect can provide this information. > > More advanced functionality like Kinect's depth information probably > needs more study and experience before we start thinking about adding it > to the language itself. On Wed, 27 Jun 2012, Robert O'Callahan wrote: > > If we were going to support anything like this, I think the best > approach would be to have a new track type that getUserMedia can return > in a MediaStream, containing depth buffer data. This seems like a solid approach. I recommend that further work on this happen in the WebRTC mailing lists where the getUserMedia() spec lives. On Fri, 29 Jun 2012, Jes�s Ruiz Garc�a wrote: > > Seeing that my proposal has not been completely rejected, could I add > this to the Category: Proposals for the Wiki?: > http://wiki.whatwg.org/wiki/Category:Proposals Sure, but the mailing lists are what matter at the end of the day. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for public data in drag events
On Thu, 21 Jun 2012, Trevor Burnham wrote: > > I've been using HTML drag-and-drop > (http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html) > in a project, but I've run into one limitation that seems severe to me: > There is no direct way to determine what the source node is from a > dragenter, dragover, or dragleave event. This makes it difficult to > support use cases where elements react to those events differently > depending on what is being dragged over them. This is intentional, because that source node could be from a Web page in another origin, another browser, or indeed, an app that isn't even a browser. So there's no real sane way to do it. > I understand that the reason for this is cross-document drags: In > addition to security implications, obtaining a reference to a DOM node > in another document simply wouldn't make sense. Therefore, the > dataTransfer object only allows serialized data. Unfortunately, > dataTransfer is only appropriate for carrying data to the drop target. > There is no mechanism for providing data to intermediate drag event > receivers, except for the "types" attributes on the dataTransfer object. > "types" can be used to carry data that you want to make public > (http://stackoverflow.com/a/11089592/66226), but this is clearly a hack > and it carries some limitations. Most notably, the spec requires that > data type strings be converted to ASCII lowercase. > > Therefore, I'd like to propose the addition of a "publicData" object on > all drag events. It would have the same interface and behavior as the > dataTransfer object, with the sole exception that it would be read-only > in all events where dataTransfer is protected. That is, publicData would > be read/write in dragStart, and read-only in all other drag-and-drop > events. That's an interesting idea. I suppose we could expose it using a custom type in cross-app OS dnd situations, too. Could you elaborate on your use case? Are there cross-window use cases for this? (For in-window cases, you could instead just use a global.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Thu, 30 Aug 2012, Jonas Sicking wrote: > > > > That's what the spec says, no? > > I thought so, but the comments in this thread made me think otherwise. > If that's the case then I'm happy. I strongly recommend only believing what the spec says, not what is said in threads. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Thu, 30 Aug 2012, Jonas Sicking wrote: > On Wed, Aug 29, 2012 at 8:34 PM, Ian Hickson wrote: > > On Sun, 17 Jun 2012, Jonas Sicking wrote: > >> > On Wed, 25 Apr 2012, Jonas Sicking wrote: > >> >> > >> >> Hmm.. how long as that been the case? I thought that when we > >> >> originally implemented @defer we ran them before DOMContentLoaded was > >> >> fired for various internal sanity reasons as well as because it gave > >> >> authors better migration paths. > >> >> > >> >> It seems nice to me to be able to depend on that all scripts have run > >> >> by the time that DOMContentLoaded is fired. Except for async scripts > >> >> of course, which are always unreliable as to when and which order > >> >> they execute. I.e. async scripts is an explicit footgun, but I'd > >> >> rather have fewer of those. > >> > > >> > I haven't changed the spec here. I don't really see what we gain by > >> > making the "stop parsing" algorithm different in this way. > >> > >> Different in what way? From what? > > > > Different from what it says now in the way you propose above (having > > appendChild-inserted
Re: [whatwg] At Inclusion (a declarative way to "Ajaxise" a website)
On Sun, 17 Jun 2012, Florent FAYOLLE wrote: > > I have written a proposal that introduces a new way to include remote > contents into the document [...] On Sun, 17 Jun 2012, Peter Beverloo wrote: > > Without having read your proposal in detail, it seems like seamless > iframes in combination with should address the majority of > your use-case: > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless On Mon, 18 Jun 2012, Florent FAYOLLE wrote: > > That seems to cover a part of the use-case, indeed. However, using > Javascript instead of a declarative way to update the URL, I think, have > a major drawback: ensuring the indexation is not trivial. Having a way to specify in the URL what to put into s would indeed be an interesting idea. XFrames was a massively overengineered attempt at solving that solution, but maybe aspects of that idea could be resurrected? Is there any browser vendor interest in addressing this? (BTW, it may be worth reminding people of this FAQ entry that discusses how to propose new ideas: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F In particular, a more careful examination of use cases and input from browser vendors is really important to a proposal's chances of success.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMContentLoaded, load and current document readiness
On Sun, 17 Jun 2012, Jonas Sicking wrote: > > On Wed, 25 Apr 2012, Jonas Sicking wrote: > >> > >> Hmm.. how long as that been the case? I thought that when we > >> originally implemented @defer we ran them before DOMContentLoaded was > >> fired for various internal sanity reasons as well as because it gave > >> authors better migration paths. > >> > >> It seems nice to me to be able to depend on that all scripts have run > >> by the time that DOMContentLoaded is fired. Except for async scripts > >> of course, which are always unreliable as to when and which order > >> they execute. I.e. async scripts is an explicit footgun, but I'd > >> rather have fewer of those. > > > > I haven't changed the spec here. I don't really see what we gain by > > making the "stop parsing" algorithm different in this way. > > Different in what way? From what? Different from what it says now in the way you propose above (having appendChild-inserted
Re: [whatwg] Should editable elements have placeholder attribute?
On Sun, 17 Jun 2012, Aryeh Gregor wrote:
> On Thu, Jun 14, 2012 at 1:11 AM, Ian Hickson wrote:
> > I strongly disagree. and are high-level constructs,
> > so it's fine for them to be defined by the UA's platform. But
> > contenteditable is a very low-level primitive. We can't just punt on
> > how it interacts with CSS; otherwise people will have no way to
> > reliably make UIs with it.
>
> I don't know why you think contenteditable is "lower-level" than
> input/textarea.
By "high level" I mean something that is self-contained, usable as a
standalone feature, which typically integrates with other features in an
atomic fashion; "lower-level", then, means something that in comparison
requires more work to use, can only be used in conjunction with something
else, etc. By analogy, a fruit juice box is high-level: it comes with its
own straw, it doesn't need any additional tools to open it, it provides a
final product without requiring any additional work. On the other hand, a
can of frozen grape concentrate requires a bowl in which to mix the
concentrate and some water, a spoon to stir them together, a jug from
which to pour the result, a glass in which to pour it and from which to
drink the resulting fruit juice.
is a high-level construct: it provides a self-contained
place in which text can be entered, it plugs straight into the form
submission system, it exposes hooks for setting the value or retrieving
the user's input that do not require knowing how the control works.
contenteditable="", on the other hand, exposes the DOM directly, has no
integration with other features like form submission, has a much less
obvious boundary between it and surrounding content... if you want to use
it in real content, there's no way to do it without script of some kind,
and if you want to use it to do anything especially compelling, you need a
lot of script (to provide all the UI for formatting, etc).
This isn't a criticism of contenteditable="". Low-level primitives are the
building blocks of platforms. But it does mean that we have different
tradeoffs to make in the designs of the features.
> >> In the end this is the check that I'm using at the moment (I didn't
> >> perform extensive tests, just enough to check that it seemed to work)
> >>
> >> var value = data.replace( /[\n|\t]*/g, '' ).toLowerCase();
> >> if ( !value || value == '' || value == ' ' || value ==
> >> '' || value == ' ' )
> >> return true;
> >
> > Now there's a problem we should fix. Having five different representations
> > of "nothing" seems like a terrible position for us to be in.
>
> If you type some stuff and then delete it all, the desired result will
> vary based on lots of factors, e.g.:
>
> * Whether or is being used for paragraph separators. Both
> and might make sense for "nothing",
> depending. This is author-configurable using the
> defaultParagraphSeparator command.
>
> * Whether there was any styling present before. If all the text was
> previously bold, for instance, deleting everything might result in
> something like , because per spec, deletion doesn't
> remove style tags from empty lines.
>
> * Whether there was any other special markup. If something (like
> execCommand("insertHTML")) made the first line have , then
> deleting everything would result in .
>
> * What the author specified as the initial contents of the editable
> area. If you have to start with, and
> the user puts the cursor there and then types "foo" and then deletes
> it, you'll go back to having just , because nothing ever inserted
> a or or anything. (As soon as the user hits Enter, both the
> old and new lines are wrapped in a paragraph separator per spec,
> although only IE/Opera do this right now.)
>
> Really, you can have any HTML markup at all in contenteditable, and we
> can't avoid that. There's not going to be any reliable way to figure
> out what "nothing" is if you can't answer the same question for
> arbitrary HTML.
Maybe the right way to detect "nothing" is to compare textContent against
"" and then to look for specific elements that count as palpable content,
like . Would it make sense to provide an API for that?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for readyState behavior
On Mon, 16 Jul 2012, Henri Sivonen wrote: > >> > >> 4) Whenever a transition to "interactive" is made, "DOMContentLoaded" > >> must eventually get fired later if the document stays in a state where > >> events can fire on it. > >> Rationale: > >>* This seems sensible for consistency with the common case. > >> Currently, there are cases where Firefox fires DOMContentLoaded > >> without a transition to "interactive" or transitions to "interactive" > >> without ever firing DOMContentLoaded, but these cases are inconsistent > >> with other browsers, so it's hard to believe they are well-considered > >> compatibility features. > >> Delta from the spec: Same as for point 3. > > > > Disagreed. IMHO DOMContentLoaded is equivalent to 'load', just a bit > > earlier (it's basically 'load' but before the scripts have run). In fact, > > I'd specifically define DOMContentLoaded as meaning "the DOM content was > > completely loaded", which clearly can't happen if the parser aborted. > > Could you "please leave your sense of logic at the door" instead of > rocking the interop boat like this? We're talking about when a document gets aborted here. Interop really isn't particularly critical. I think this is an area where it makes a lot more sense to keep things simple. The platform is confusing enough as it is without us having confusing behaviour where it's not strictly necessary. > I think that in a situation like this change is more harmful and likely > to break something than the sort of logic you offered is useful. Can you elaborate on how any changes here are really likely to break anything? I'm finding it hard to see why this area is interop-sensitive. > >> 10) XSLT error pages don't count as aborts but instead as non-aborted > >> loads of the error page. > >> Rationale: > >>* Makes parent pages less confused about events they are waiting. > >>* Already true except for bugs in Firefox which is the only > >> browser with XSLT error pages. > >> Delta from the spec: Make explicit in spec. > > > > I haven't defined this because to define this I'd have to define a ton of > > infrastructure that explains how XSLT works in the first place, and I'm > > still waiting for the XSLT community to write the tests that demonstrate > > what the requirements should be: > > > >https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689 > > I don't think you need to spec infrastructure to define a high-level > expectation that loads with XSLT errors are supposed to finish as if > they were successful loads rather than aborted loads. IMHO there's no value in making vague meaningless statements (which the statement "loads with XSLT errors are supposed to finish as if they were successful loads" would be without defining "loads" for XSLT, "finish" for such loads, and "as if"). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Readiness of script-created documents
On Fri, 15 Jun 2012, Henri Sivonen wrote:
> On Tue, Jun 12, 2012 at 1:46 AM, Ian Hickson wrote:
> > When a document is aborted the state is more or less left exactly as
> > it was when it was aborted. This includes the readiness state. It also
> > means no events fire (e.g. no 'load', 'unload', or 'error' events), a
> > number of scripts just get abandoned without executing, appcache stuff
> > gets abandoned, queued calls to window.print() get forgotten, etc.
> >
> > Aborting a document is a very heavy-handed measure. Documents are not
> > expected to last long after they have been aborted, typically. Pages
> > aren't expected to remain functional beyond that point.
>
> That's not reality in all browsers right now, and I think it doesn't
> make sense to make that the reality. That is, there already browsers
> that transition readyState to "complete" upon aborting the parser and I
> think doing that makes sense (and I want to change Gecko to do that,
> too)
With you up to here. The spec has been updated to transition to 'complete'
after it is aborted, on the principle that 'loading' means that the parser
is still active.
> because a non-"complete" readyState is a promise to fire an "load" event
> later.
That's not the case, though.
> I think it's a bad idea to leave a document into the "loading" state
> when the browser engine knows that it won't fire and "load" event for
> the document.
That's fair enough.
> Basically, I think the platform should maximize the chances of the
> following code pattern causing doStuff to run once the document has
> completely loaded:
> if (document.readyState == "complete") {
> setTimeout(doStuff, 0);
> } else {
> document.addEventListener("load", doStuff);
> }
I agree, but we're not talking about documents that are completely loaded
here. We're talking about documents that get aborted. Documents that are
aborted do not need to work, they were aborted precisely because they
don't need to work and are no longer needed.
No 'load' event fires after a document is aborted, because it didn't load.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Domain transfer security
On Tue, 12 Jun 2012, Simon Brown wrote: > > I have thought of a possible security problem that may be reduced with a > change to the specifications (though I'm not sure exactly how). > > 1. An attacker has control of a popular site. > 2. The attacker buys a valuable domain. > 3. The attacker creates a page on the site that sends all > cookies/localstorage/etc. to their site. > 4. The attacker enables caching the page with appcache. > 5. The attacker embeds the page in a small iframe on the popular site, > so that anyone visiting the popular site has the page cached. > 6. The attacker sells the domain on. > 7. The popular site continues to receive traffic, and people who > regularly visit both sites have their session/data/etc. on the new site > compromised. > > I guess one possible solution would be to allow SSL sites to specify > through a header that only appcaches from certain public keys to be > carried over, though this seems quite complicated and wouldn't work for > the majority of websites. The new domain just has to return 404 for the old manifest for the cache to be blown away as soon as the user loads the cache. It's unlikely that many, if any, caches would survive long enough for the user to enter credentials in a way that would enable an attack, as far as I can tell. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r7128 - [giow] (2) Try to define img synchronous loading. Affected topics: HTML
On Tue, 12 Jun 2012, Simon Pieters wrote: > > The potentially CORS-enabled fetch algorithm ignores the state of the > crossorigin attribute when the URL is same-origin. Maybe the sync > loading logic needs to align with that behavior. The problem is that it doesn't actually entirely ignore it, in particular if it's a cross-origin redirect. I guess we could work around that by detecting the case of the image having been loaded entirely same-origin, and then sticking into the /list of available images/ three separate entries, one for each possible mode? But then what do we do if one of the modes is already present, e.g. because we had done an Anonymous fetch and it had involved a cross-origin redirect, but later we do a With Credentials fetch and it doesn't (staying same-origin)? Keeping it just predicated on the crossorigin mode means that the vast majority of the time, things work predictably and reliably. And it's easy to implement, in comparison. The only loss is that we don't get sync loading in the weird case of someone loading an image with and without CORS when that image is all same-origin, when we normally could, but how often is that going to happen and will anyone care? On Tue, 12 Jun 2012, Boris Zbarsky wrote: > > Hmm. On the face of it, this seems like a bug when open redirectors are > involved... Is this what UAs implement in practice? On Wed, 13 Jun 2012, Simon Pieters wrote: > > If it redirects, it switches to CORS. However, there are some bugs in > the spec... [...] Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for change in recommendation for loading behavior of non-applicable stylesheets
lazy loading. (The only requirement is that scripts block if there's style sheets that could affect them.) The spec also says, specifically for resources, that: # User agents may opt to only try to obtain such resources when they are # needed, instead of pro-actively fetching all the external resources # that are not applied. -- 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."
ted > differently from any other HTML attribute? In no other HTML attribute is > the author barred from explicitly specifying a default value. That's not true, actually. By and large I try pretty hard to make it so that there is no default value, so that the problem doesn't turn up. For example, looking at the global attributes, you can't set the default value for any of "contenteditable", "dir", "draggable", "dropzone", "hidden", "inert", "itemid", "itemscope", "lang", "spellcheck", "title", and "translate". For attributes like "accesskey", "class", "itemref", and "style" you can technically set it to the default value, but the default value is trivial (the empty string), so it's not a cargo-cult problem. For other attributes, e.g. "contextmenu", "id", "itemprop", "itemtype", and "tabindex" it is technically possible to give the default value, but as with role="", it's not conforming. So all the global attributes are consistent with the decision for role="". > To take consistency to its logical end, the ARIA semantic default from > the table might be considered the "missing-value-default" found in other > HTML attributes. Is there something I'm missing that makes this Not A > Good Idea? You'll notice that most missing value defaults, at least for the global attributes that might get copied-and-pasted around more, are not in fact valid keywords. > To get down to specifics, I'd expect: > > > > > > to be identical in the spec's eyes, excepting the first being the preferred > (but not required) form. The processing model for role="" is defined in the ARIA specs, so whether the second and third examples above mean the same is up to that spec. The default is up to the HTML spec. However, what we're discussing here is not what it means, but whether it should be allowed. > > For example, expert A writes a Web page with some redundant roles, > > author B copies markup from that page and changes it to suit their > > needs, but ignores the previously "redundant" bits and thus ends up > > with conflicting information instead of redundant information. Page > > ends up being sub-optimally accessible, because the previously > > "redundant" accessibility annotations now conflict with the page's > > real semantics, and are wrong. > > I don't see how this differs materially from someone copying a batch of > code with valid ARIA markup in place, and changing it so the content is > at odds with the valid "non-redundant" ARIA markup. And, in fact, > allowing the author to specify the default would preserve ARIA in > cargo-culted code if the elements themselves get changed to, say, > 's. I'm not sure I understand what you mean. Can you give an example? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why won't you let us make our own HTML5 browsers?
On Fri, 8 Jun 2012, Mark Callow wrote: > On 08/06/2012 06:09, Ian Hickson wrote: > > The dire warning doesn't work. I'm just saying that's the direction > > that operating system vendors have been going in; that disallowing it > > in the browser case is not a different direction, it's consistent with > > the industry's direction as a whole. > > The platform providers want control so they can extract money from > application developers; they do it under the guise of safety & security > so people will go along with it. Governments get control over people in > the same way. > > In both cases it is an existential threat to freedom and civil > liberties. If one works from these assumptions, why would we assume that it is nonetheless possible for us to specify something that works against these motivations? Putting something in the spec doesn't magically make it appear in browsers. On Fri, 27 Jul 2012, Nils Dagsson Moskopp wrote: > > (Btw, Hixie stated the following to be a possibility: „Google ships > support for the codec for long enough without getting sued that Apple's > concern regarding submarine patents is reduced.“. Any update on that?) None so far that I'm aware of. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] tabindexscope
On Fri, 8 Jun 2012, Silvia Pfeiffer wrote: > On Fri, Jun 8, 2012 at 6:10 AM, Ian Hickson wrote: > > On Thu, 7 Jun 2012, Silvia Pfeiffer wrote: > >> > > >> > Can you give some examples of real-world pages where the tabindex > >> > attribute has been used (with difficulty due to the lack of > >> > scoping), where nav-index is not the right solution, and where the > >> > UA following platform conventions for tab order doesn't or wouldn't > >> > end up in a good UI, that show that this feature would be useful? > >> > I'm having trouble picturing it, and the frequent references above > >> > to positioning and other CSS layout features is confusing me. > >> > >> Imagine a video player with special functionality and a special tab > >> order defined (e.g. the current YouTube HTML5 player has that because > >> the logical visual layout of the control element is different from > >> the DOM order). On the video's home page you can pre-define the tab > >> order and make sure it fits with the page. But when it's embedded in > >> another Web page, and that special tab order potentially conflicts > >> with the page's tab order, since the embed code can't really know > >> what index number to start with, since you don't know anything about > >> the page into which it is embedded. I believe nav-index would have > >> the same problem, but a tabindexscope would solve the issue. > > > > I don't think this is really a good use case for three reasons: > > > > - You describe the intended tab order as being the visual order, which > > is, per spec, the order the UA should be using in the first place if > > that's what the platform does, not the DOM order; > > I haven't seen a spec that says how browsers should implement the > default tab order - is there one? The spec says that "The user agent should follow platform conventions to determine if the element's tabindex focus flag is set and, if so, whether the element can be reached using sequential focus navigation, and if so, what its relative order should be". > Typically it has been implemented to be DOM order with the ability given > to Web Devs the ability to override this using @tabindex. As long as > there is no spec requiring browsers to implement the default tab order > to be the visual order (given absolutely placed elements, floating > elements etc), I don't think we can make any assumptions about it. If we're working from the assumption that Web browsers aren't matching the spec, then it's not clear that changing the spec is in any way helpful. > > - Typically a video player like this would be embedded using an > > , which introduces a new tab order scope anyway; > > Yes, that solves this issue oftentimes. But what happens when you want > to provide developers a HTML fragment without for cut and paste > and it requires tabindex fixes? Do you have an example of this happening? > It's pretty annoying for the Web dev to have to go through that snippet > and manually adapt it to their Website. Assuming it comes from a content > mgmt system, you'd need to include a parameter for the embedding that > adapts the snippet's tabindex attribute values when including it with a > dependency on the Web page on which it renders. It would be pretty > fragile. I'm not saying it's inconceivable that a scoping mechanism for tab index would be useful in some cases. However, we can't possibly add everything that could have the remotest possibility of being useful. We have to implement things that have clear needs shown by real Web sites in volume. > > - Widgets in general will in the future be designed in self-contained > > components, which should IMHO be defined as a tab order scope -- we > > don't need an attribute in HTML to support that. > > How would that work? Is there a spec somewhere? There are many, e.g. XBL2, sXBL, Web Components, the SVG thing that predated sXBL, etc. On Fri, 8 Jun 2012, Silvia Pfeiffer wrote: > > Actually, I'm just thinking it through for the content management use > case (in particular here the YouTube case). I don't think I can solve > this without a @tabindexscope. > > Assuming the video player is in a Web page and has a custom tab order of > the elements defined where the first one will start at value n and the > others successively have value n+1, this will still dominate all other > elements on the page that come before it. I can't even change that n > value dynamically for the page, because th
Re: [whatwg] Proposal: "Offline-Capable" Meta Tag and API Indicates Application's Ability to Function Without Network Connection
On Thu, 7 Jun 2012, Brian Blakely wrote: > On Wed, Jun 6, 2012 at 7:49 PM, Ian Hickson wrote: > > On Fri, 27 Jan 2012, Brian Blakely wrote: > > > > > > This proposal deals chiefly with standardizing the messaging around > > > that. The developer sets up the application to be ready for offline > > > use (via App Cache, localStorage, IndexedDB, cookies, etc), and > > > informs the UA when the user can go off the wire. The UA then > > > informs the user in a predictable way that will become familiar to > > > them as they continue to use that particular client. > > > > > > Background downloading and other mechanics introduced in this thread > > > enable a native-like app download process that is, again, always the > > > same on the same UA, instead of varying from application to > > > application. > > > > I think we should wait for sites to start showing their own UI for > > this kind of thing -- "ok, I'm now fully cached" -- before we add a > > mechanism for the script to ask the UA to show UI for this. Without > > the experience gained from authors doing it themselves, we don't > > really have enough information about how to design the feature. > > I agree to the extent that nobody knows what works best at this point > (though I could point to some examples of good implementations). UA > implementation would certainly evolve, just as Fullscreen > implementations have been. > > My major concern is that, as web developers learn, leverage, and master > various offline technologies, widespread adoption alone could take > years, and that is before developers begin to finesse their UIs. > > The main purpose of the proposal is to accelerate the uptake of the > offline Web. A UA hook for users helps to break us away from "the web > is online-only, forever" and a simple API for a dev will encourage > implementation. I don't think that rushing to add a new feature to the spec -- which may or may not be implemented by browsers, but which almost certainly won't be exactly what authors need since it'll be done without the benefit of deployment experience -- will do anything positive to accelrate the uptake of the offline Web. Standards development takes time, and has to be done carefully. Mistakes can be very costly and last a long time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Tue, 28 Aug 2012, Boris Zbarsky wrote: > > Ah, I see. So is what you're proposing that stylesheets that are > inserted by a "nested tokenizer" not block scripts in general, but > stylesheets that are inserted by a top-level tokenizer block scripts as > usual? > > Or is what you're proposing that scripts that are inserted by a "nested > tokenizer" not block on stylesheets? The latter. The blocking only affects scripts that are "prepare the script"ed by the "top-level" parser, not a reentrant parser. (This is in the spec if you want to examine the precise wording I'm proposing here.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Tue, 28 Aug 2012, Boris Zbarsky wrote: > On 8/28/12 12:46 AM, Ian Hickson wrote: > > I've updated the spec to not block on style sheets for nested parser's > > scripts. > > I'm not sure I follow. What is not going to block on what with this change? > > As far as I can tell, "0 1 2" in your testcase at > http://damowmow.com/playground/demos/document-write-and-scripts/002.html is > consistent with the following order of execution: > > 1) x=0 > 2) x1=0,x=1 (nothing else has run yet because we're waiting on > blank.js) > 3) setTimeout fires, sets x2 = 1 > 3) second external script runs, sets x = 2. There's only one external script. The script after the style sheet is internal. If it blocks, you get "0 1 2" (when x2 gets set to x in the timeout, it's still x=1, because the next script, which sets x=2, hasn't run). In Gecko, however, that internal script doesn't block, and so the timeout runs after x has been set to 2. Hence "0 2 2". The reason for having the external script in 002.html is that it causes document.write() to return right there (except in IE9, but that's another story, not sure what that's about), so you can tell the difference between how the internal
Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior
On Wed, 6 Jun 2012, Boris Zbarsky wrote:
> >
> > Unless I'm mistaken, nothing in the HTML spec does anything
> > differently based on whether a script comes from document.write() or
> > not. The information about whether a character in the tokeniser came
> > from the network, document.write() during a network parse, or
> > document.write() on a completely script-written document, is not
> > stored along with the character in the tokeniser's input stream.
>
> Oh, I see. The problem with that is situations like this script:
>
> var x = 0;
> document.write("" +
> "
Re: [whatwg] Various HTML element feedback
On Wed, 6 Jun 2012, Henri Sivonen wrote: > On Wed, Jun 6, 2012 at 2:53 AM, Ian Hickson wrote: > >> That might be realistic, especially there is no significant semantic > >> clarification in sight in general. This raises the question why we > >> could not just return to the original design with some physical > >> markup like , , and together with that was added > >> later. > > > > I think you'll find the "original design" of HTML isn't what you think > > it is (or at least, it's certainly not as presentational as you imply > > above), but that's neither here nor there. > > Is there a record of design between > http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html > and http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt ? There's some in-between steps, e.g.: http://lists.w3.org/Archives/Public/www-talk/1992NovDec/0155.html > >> So why not simply define recommended and describe , , > >> , and as deprecated but supported alternatives? > > > > What benefit does empty deprecation have? It's not like we can ever > > remove these elements altogether. What harm do they cause? > > The harm is the wasted time spent worrying about and debating which > "semantic" alternative for italics to use. I think this harm is dramatically reduced relative to the HTML4 days by the extensive use of examples and detailed descriptions in the spec now. If people are still having long debates, please don't hesitate to point me to them so I can clarify them in the spec. That's what a living standard is good for, after all. > > If we have to keep them, we are better served by embracing them and > > giving them renewed purpose and vigour, rather than being ashamed of > > them. > > I think we have to keep them, because trying to declare them invalid > would cause people to do a lot of pointless work, too, but I think we > could still be ashamed of them. I don't think that's healthy. > > Note that as it is specified, can be used instead of with > > basically no loss of semantics. (This is because the spec defines > > "paragraph" in a way that doesn't depend on .) > > Is there any known example of a piece of software that needs to care > about the concept of "paragraph" and uses the rules given in the spec > for determining what constituted "paragraphs"? No, this is just to make it clear that you don't need to use , and to short-circuit arguments about whether a is in a paragraph, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Various HTML element feedback
On Wed, 6 Jun 2012, Jukka K. Korpela wrote: > 2012-06-06 2:53, Ian Hickson wrote: > > > > > > I have rather been optimistic about future developments for markup > > > elements that have been defined exactly enough to warrant meaningful > > > semantics-based processing. For example, most of the uses mentioned > > > in current text imply that element contents should be kept > > > intact in automatic language translation. > > > > That continues to be the case, so I don't know why you conclude that > > using it is now pointless. > > It is worse than pointless, if the definition of covers "a term > used as a placeholder in prose". Such expressions should definitely not > be kept intact in automatic language translation. They shouldn't be kept intact, but they still need special semantic processing to not break the page's meaning during translation (e.g. ensuring that the same variable name is always translated the same way). > > > So why not simply define recommended and describe ,, > > > , and as deprecated but supported alternatives? > > > > What benefit does empty deprecation have? > > Declaring some features as "obsolete" is effectively deprecation; I just > used the term "deprecate" as per HTML 4.01 because I find it more > descriptive. Anyway, defining those elements as deprecated/obsolete > would be no less and no more "empty" than the current statements about > obsolete status. Validators/checkers would issue messages (hopefully > just warnings) about them, and tutorials would probably describe them as > secondary if at all. I don't see any benefit to obsoleting these elements. They are useful for various purposes. Even the HTML spec uses them (all of the above, in fact) to obtain special behaviour (e.g. the cross-referencing system uses ). In general having a variety of elements provides authors with good hooks for styling, too. > Reducing alternatives, from five to one in this case, makes the > recommendations simpler and helps authors because they need not spend > time in making choices between the elements. Such choices can be tough, > if you try to play by the declared "semantics", especially if it is > vague (to a normal reader of a spec). > > My point is: either make elements like , , , , > defined so that the differences can be utilized in automatic processing, > or just bundle them together, to . I certainly agree that we shouldn't go to a DocBook level of element variety, but reducing the avilable elements to a mere handful doesn't make any sense either. We have to strike a balance, taking into account what elements have historically been available (and thus which authors are familiar with), what use cases might argue for new ones, which elements have been most used or not used, etc. > > It's not like we can ever remove these elements altogether. > > Oh, in 20 or 30 years, I think browsers could support to some of them. I'm not sure what you meant to write, but I don't see why 1992-2012 would be harder than 2012-2032 in terms of dropping these elements. > > What harm do they cause? > > Unnecessary complication to the language, artificial "semantics" that do > not actually define meanings, and confusion among those authors who try > to take semantics and specifications seriously. Oh, and pointless > variation in markup and added complexity of styling. I disagree that these are really serious problems, or that their magnitude outweights the benefits here. > > If we have to keep them, we are better served by embracing them and > > giving them renewed purpose and vigour, rather than being ashamed of > > them. > > I think this summarizes well the idea behind some of the most contrived > "semantic" definitions. It was a brave attempt, but it failed. No normal > author will ever get your idea of the new meaning for and , for > example. I guess we shall see. :-) > And since, for example, the markup needs to be supported for a > long time, how come *it* has not got a new, semantic definition? I didn't start from and look for a use case. People presented use cases, and when looking for a solution, fit the bill. Same with , etc. We did at one point have in the spec, but the use case that supported its inclusion was later solved in a different way (I forget what it was) and we ended up removing it again. If a use case is presented for which is a good fit, we can use it again. > > > This would make authoring simpler without any real cost. There’s > > > little reason to tell authors to use “semantic markup” if we > > > don’t think it has
Re: [whatwg] MediaController feedback
On Tue, 5 Jun 2012, Jer Noble wrote: > >> > >> The overall purpose of the modifications is to achieve the following: > >> when controller.play() is called, all slaved media elements > >> unconditionally will begin playing. > > > > I don't think this is a good idea. If the user has paused one of the > > slaves, and then pauses and resumes the whole thing, the paused media > > element shouldn't resume. It should remain paused. (I meant author, not user, here.) > With JavaScript, it's certainly possible for a page author to play() or > pause() a slaved media element directly, but that author could just as > easily remove the media element from the media group / media controller. > > > [...] > > > > That only works if there's JavaScript doing the removing. The idea > > here is that this should all work even without any JS, just with UA > > UI. > > With just the UA UI, the behavior would be exactly the same [...] If you remove the element from the media controller, the media controller's timeline changes. It'll be quite common for there to be videos that are not currently playing, e.g. sign-language tracks. If we change anything here, I think it would be the currently required UI behaviour which requires all the videos to start playing when the user overrides the JS-provided controls and just uses the UA controls. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts
On Wed, 6 Jun 2012, Charlie Reis wrote: > > I've posted a new proposal to the WhatWG wiki to give web sites a way > to open a link in an unrelated browsing context. These links would open > in a new window with no script connections back to the original site, > which is useful for web apps like Gmail that open user-contributed > links. Also, this could allow multi-process browsers like Google Chrome > to open the new page in a separate process. > > Any feedback on the proposal is appreciated! > http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts It's not entirely clear to me what the desired behaviour is here. Which of the following are considered features that we need to provide? Which are secondary goals, which are non-goals, which are anti-goals? + have "window.opener" not be set + have the window.name of the new page be set to "" + have the window of the new page not be able to reach the opener via a named window.open() or target="" + have the referer header be cleared on the load of the new page + have the sessionStorage not be cloned for the new page's browsing context + have the new page use a different event loop if possible (new process) + have the new page be in a different unit of related browsing contexts + have the new page be in a new browsing context + have the new page be in the same browsing context Does this need to be done from window.open()? From ? From ? Is this a symmetric feature? At a more fundamental level: what are the use cases here? Is it just e-mail clients that want to open links? What are the attack scenarios? Is it just links in e-mails getting at the e-mail app somehow? Without more details like the above it's hard to evaluate the proposals. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=barcode?
On Wed, 3 Aug 2011, Tab Atkins Jr. wrote: > On Wed, Aug 3, 2011 at 8:50 AM, Randy wrote: > > On top of that, the vast majority of these readers just translate it > > back to text. It's just another input "device", as barcodes are fixed > > (and sometimes standardized) fonts. > > True, so this is perhaps closer to an IME hint, as has been suggested > for a couple of other input types. Do you mean something like inputmode=barcode? Can you elaborate on how that would work? It's an intriguing idea, but I'm not sure I follow quite how to specify it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Serialization of expandos on String / Boolean / Number objects
On Thu, 23 Aug 2012, Dumez, Christophe wrote:
>
> The latest specification of the structured clone algorithm [1] does not
> indicate that we are supposed to serialize expandos on objects such as
> String, Boolean or Number.
>
> For example:
> var str = new String("test");
> str.foo = 3;
> window.postMessage(str, "*");
>
> Isn't str.foo property supposed to be serialized? If I read the
> specification correctly, it is not:
> """
> If input is a String object
>
> Let output be a newly constructed String object with the same
> value as input.
> """
>
> Is this behavior really intended? I think it would make sense to
> serialize the properties attached to such objects.
On Thu, 23 Aug 2012, Tab Atkins Jr. wrote:
>
> As far as I can tell, the Structured Clone algorithm has mostly bottomed
> out into JSON, so the loss of expandos on those builtins is intentional
> - keeping them would mean serializing them as objects, rather than as
> literals.
This is correct. With some exceptions (like Blobs and supporting cycles),
we are trying to be close to JSON in terms of the basic data structure.
Supporting things like Strings as primitive types would also make
conversion to other languages much more complicated (most languages don't
have a concept of "object whose value is a string plus a dictionary").
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Conformance checking of missing alternative content for images
ulkner wrote:
>
> *Note:* in terms of the accessible name calculation for an img element,
> if the image does not have aria-label or an aria-labelledby or an alt
> attribute, but does have a title attribute, then the title attribute is
> used as the accessible name. From an accessibility API perspective, no
> distinction is indicated as to the source of the accessible name (apart
> from in the Mac AX API).
Note that the spec doesn't currently say to do this; it says what I said
above, namely that if there's no alt="", the presence of the image should
be indicated, and the caption information provided as caption information.
On Wed, 1 Aug 2012, Philip Jägenstedt wrote:
>
> To be very clear, you agree with the spec, think that WebKit is wrong
> and would not offer any applause if Opera were to use the title
> attribute to replace images when images are disabled and there is no alt
> attribute?
I would applaud doing what the spec says, as I described above. :-)
The spec is pretty clear here, IMHO. (I've tried to make it even clearer.)
On Wed, 1 Aug 2012, Henri Sivonen wrote:
>
> In addition to image considerations, I think
> http://www.whatwg.org/specs/web-apps/current-work/#footnotes is bad
> advice.
On Wed, 1 Aug 2012, Philip Jägenstedt wrote:
>
> Yeah, that looks like a pretty bad idea, even for sighted users on
> desktop browsers, unless you also add span[title] { border-bottom: 1px
> dotted black; } or similar to your CSS to make it more discoverable.
> Removing that advice seems like a good idea.
I've added a warning in that section and changed it from SHOULD to COULD
for now. Since this is an accessibility problem, I remain hopeful that
browser vendors will eventually fix their handling of title="".
I've also added a note about using CSS if title="" is used.
On Wed, 1 Aug 2012, Ian Hickson wrote:
> On Wed, 25 Jul 2012, Leif Halvard Silli wrote:
> >
> > How about simply introducing a @generator attribute:
> >
> >
>
> In the past I have argued against this, on the basis that it is highly
> likely to be abused and actually make things worse. (The idea has been
> brought up numerous times over the past few years, in many forms.)
>
> However, a few years of experience with the "generator" idea have
> not led Henri and Mike (validator authors) to feel that the problem has
> been suitably addressed, and Mike is now implementing alternatives, so
> clearly it is time for me to revisit that. :-)
>
> We briefly brainstormed some ideas on #whatwg earlier tonight, and one
> name in particular that I think could work is the absurdly long
>
>
>
> This has several key characteristics that I think are good:
>
> - it's long, so people aren't going to want to type it out
> - it's long, so it will stick out in copy-and-paste scenarios
> - it's emminently searchable (long unique term) and so will likely lead
>to good documentation if it's adopted
> - the "generator" part implies that it's for use by generators, and may
>discourage authors from using it
> - the "unable" and "required" parts make it obvious that using this
>attribute is an act of last resort
>
> This attribute would be non-conforming except when provided in markup
> generated by user agents that find themselves with an image and no
> suitable alt="" text. It would be a third option in the "Images whose
> contents are not known" section of the spec. It would be mentioned in
> the "Guidance for markup generators" section, along with some text about
> using one of the other two alternatives when the image in question is
> the center of attention on the page (as in the Flickr case), rather than
> using this new attribute. It would replace the "generator" exception in
> the "Guidance for conformance checkers" section. The note in the
> "generator" section would be removed.
I've now added this to the spec.
On Wed, 1 Aug 2012, Jukka K. Korpela wrote:
> 2012-08-01 10:56, Ian Hickson wrote:
> >
> > Only generators are in a position where they might have to include
> > images for which they lack the ability to provide alt texts.
>
> A simple counter-example to that: A human employee who has been told to
> add some images to a web page, without having been told why and with no
> instructions on alt texts.
Humans are incredibly adept at deducing context, and are quite able to
reuse to comply to unethical requests. Such a human could, ofr instance,
look at the image to determine what its meaning was, or could refuse to
add the image without clear information on w
Re: [whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly
On Mon, 20 Aug 2012, Rik Cabanier wrote: > > can you log a bug on this? > https://www.w3.org/Bugs/Public/enter_bug.cgi once it's in the system, we > can fix the wording in the spec. No need to file a bug; any e-mail sent to this list automatically ends up on the list of issues to fix and will get a response in due course. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?
On Fri, 10 Aug 2012, Markus Lanthaler wrote: > On Thursday, August 09, 2012 4:53 PM, Ian Hickson wrote: > > > > > > > > The only reason there's a MIME type at all (rather than just using > > > > JSON's directly) was to enable filtering of copy-and-paste and > > > > drag-and-drop payloads; would JSON-LD enable that also? > > > > > > Sure, I see no reason why not. > > > > Could you give an example of how? I don't understand how it would work > > if we re-use an an existing MIME type. If you have any concrete > > examples I could look at that would be ideal. > > Maybe I'm missing something but what would be the difference of re-using > an existing MIME type? There'd be no way to distinguish a microdata drag-and-drop payload from any other JSON-based (or in the case of what you're proposing, JSON-LD-based) payload in the dropzone="" filtering. > Looking at the drag and drop API the only thing that would need to be > changed is the "drag data item type string" from " > application/microdata+json" to "application/ld+json" in [1]. Then there'd be no way to determine if the payload was generated by the microdata extractor or not. > The advantage in doing so would be that a drop handler could use the > JSON-LD API to reframe the data so that it can be used more easily. What JSON-LD API? I'm not aware of any browsers that have such a thing. And why would we want to require that authors use yet another API instead of just using straight JavaScript, as you can with JSON? > > > > That seems like it is strictly more complicated (trivially so, but > > > > still). What is the advantage? > > > > > > Well, I would say there are several advantages. First of all, > > > JSON-LD is more flexible and expressive. > > > > More flexible and expressive than what? > > Than application/microdata+json. I don't understand what you mean by "flexible and expressive". Could you give an example of how JSON-LD is more flexible than JSON? I'm really confused as to what you're saying here. > JSON-LD could also be used to extract RDFa (lossless). That doesn't seem like a benefit. (Note that microdata and RDF have different data models and cannot be directly mapped from one to the other. It is highly unlikely that any other format can actually represent both of them without either some sort of data loss or a dramatically more complicated data model than microdata, both of which would be bad.) > > > It has support for string internationalization, data typing, lists > > > etc. > > > > How would this manifest itself in this context? Are you suggesting > > that we should change the microdata to JSON serialisation rules > > somehow? > > Since microdata doesn't support that, it isn't really needed in that > context. But it could harmonize the result with a lossless extraction of > RDFa for example or come very handy when interacting with Web services > exposing JSON-LD. Could you give a concrete example of a problem this solves? I'm finding it different to understand what you are proposing. > > > It also allows to distinguish between IRIs and literals (which isn't > > > the case for application/microdata+json) which is important for > > > Linked Data application. > > > > Could you give an example of how this would help an application? > > You could imagine an application that manages books and their authors. > If the author is specified in the form of an IRI, the application could > render the information in the form of a hyperlink or go even a step > further and try to automatically fetch more information about that > author. That sounds like the pie-in-the-sky reasoning that underlies most RDF arguments. :-) Could you point to a concrete example of an actual application that would benefit from having a single field have multiple types? In the case of the example you give, I think applications would in general benefit far more (in terms of ease of implementation and maintenance) from just having one field that describes the author in terms of the author's name, and one field that gives an identifier that can be used to look up the author in the database, rather than having a single field that can do one or the other but not both, or that can do both but is sometimes a multivalued array and sometimes just one value and you have to introspect each value to work out what each entry is. > > It would help if you described what precise changes you would like to > > see to the algorithms, so that I better understood the implications &
Re: [whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?
On Thu, 9 Aug 2012, Markus Lanthaler wrote: > > > > The only reason there's a MIME type at all (rather than just using > > JSON's directly) was to enable filtering of copy-and-paste and > > drag-and-drop payloads; would JSON-LD enable that also? > > Sure, I see no reason why not. Could you give an example of how? I don't understand how it would work if we re-use an an existing MIME type. If you have any concrete examples I could look at that would be ideal. > > That seems like it is strictly more complicated (trivially so, but > > still). What is the advantage? > > Well, I would say there are several advantages. First of all, JSON-LD is > more flexible and expressive. More flexible and expressive than what? > It has support for string internationalization, data typing, lists etc. How would this manifest itself in this context? Are you suggesting that we should change the microdata to JSON serialisation rules somehow? > It also allows to distinguish between IRIs and literals (which isn't the > case for application/microdata+json) which is important for Linked Data > application. Could you give an example of how this would help an application? It would help if you described what precise changes you would like to see to the algorithms, so that I better understood the implications here. > Secondly, there is an API for JSON-LD to reframe [1] a document into a > shape that might be easier to work with in a web app (I think that's the > whole point of microdata+json or am I wrong?). I don't understand what this means. > Other API calls allow e.g. to convert to and from RDF [2]. If you are > interested, there is an online JSON-LD playground [3] where you can play > with the various API calls. Last but not least it would also make web > developers life easier if there are fewer formats to support/learn. Currently, the data is just stored as JSON, it's not a new format. It's only a new MIME type to allow easier filtering in the drag-and-drop API. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?
On Wed, 8 Aug 2012, Markus Lanthaler wrote:
>
> I was wondering whether it was considered to use JSON-LD [2] instead of
> creating application/microdata+json. The resulting output would be more
> or less the same.
It wasn't. What would be the purpose of doing so?
The only reason there's a MIME type at all (rather than just using JSON's
directly) was to enable filtering of copy-and-paste and drag-and-drop
payloads; would JSON-LD enable that also?
> For example the following application/microdata+json document:
>
> {
> "items": [
> {
> "id": "http://example.com/id1";,
> "type": [ "http://example.com/type1"; ],
> "properties": {
> "property1": [ "value1" ],
> "property2": [
> {
> "id": "http://example.com/id2";,
> "type": [
> "http://example.com/type2";,
> "http://example.com/type3";
> ],
> "properties": {
> "property3": [ "http://example.com/value3"; ]
> }
> }
> ]
> }
> }
> ]
> }
>
> Could be expressed in JSON-LD as
>
> {
> "@graph": [
> {
> "@id": "http://example.com/id1";,
> "@type": [ "http://example.com/type1"; ],
> "property1": [ "value1" ],
> "property2": [
> {
> "@id": "http://example.com/id2";,
> "@type": [
> "http://example.com/type2";,
> "http://example.com/type3";
> ],
> "properties": {
> "property3": [ { "@id": "http://example.com/value3"; } ]
> }
> }
> ]
> }
> ]
> }
>
> Or, by aliasing JSON-LD's keywords even as which is almost exactly the same
> as the application/microdata+json counterpart:
>
> {
> "@context": {
> "id": "@id",
> "type": "@type",
> "items": "@graph"
> },
> "items": [
> {
> "id": "http://example.com/id1";,
> "type": [ "http://example.com/type1"; ],
> "property1": [ "value1" ],
> "property2": [
> {
> "id": "http://example.com/id2";,
> "type": [
> "http://example.com/type2";,
> "http://example.com/type3";
> ],
> "properties": {
> "property3": [ { "@id": "http://example.com/value3"; } ]
> }
> }
> ]
> }
> ]
> }
That seems like it is strictly more complicated (trivially so, but still).
What is the advantage?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A mechanism to improve form autofill
On Mon, 23 Jul 2012, Ian Hickson wrote: > > So we could define the autocomplete="" field's value as follows: [...] I've now specced this, with some minor changes. On Wed, 25 Jul 2012, David Holloway wrote: > > A "contact" address might be helpful for sites that are non-commercial in > nature. Airlines and hotels often ask for contact information such as here: > > https://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/autofill/heuristics/input/10_register_hotels.com.html?revision=89396&view=markup > > Or, optionally: > > subsection = up to one of: "shipping" or "billing" > > Where omitting the subsection covers the general case. I went with making shipping/billing optional. > > Anything other than "work", "home", and "fax"? Should it be "work-fax" > > and "home-fax"? > > "mobile", "pager"? Added those. On Wed, 25 Jul 2012, Maciej Stachowiak wrote: > > For some of these fields, autocomplete="" as a hint to autocompletion > seems sufficient. However, I think some may logically be a distinct > input type as well. Some of the information represented in the proposal > below is also redundant with existing type values (so it needs to be > specified either twice or in a conflicting way). I've added a section that details the difference between type="", inputmode="", and autocomplete="". Let me know if that doesn't answer your questions on this front. > I think cc-number is worthy of a distinctive type value. Credit card > numbers have a distinctive syntax. At the very least, they are numeric > and should trigger a numeric keyboard on touch devices and restriction > to digits. But they cannot be because it would be > wrong to format and localize the number (with comma or dot separators > for instance), and a spinner button is an obviously inappropriate > treatment. A similar consideration applies to cc-csc. These should > either be assigned distinctive types, or else we need to introduce a new > input type for a string of digits that is not to be formatted as a > number or treated as a spinner button ( or type=numeric>). I think it is essential to do that before widely > deploying these autocomplete values, or else browsers will start using > the autocomplete value to drive behavior of the control itself, which > defeats the purpose of having a separate autocomplete attribute. As far as I can tell, this is just . > cc-exp subtypes could be distinguished by input type for cases where > they are not selects. Or alternately, it would be nice if there was a > way to use in browsers that have support for it, and > the traditional two selects or two text fields. Without script, that's hard. With script it's possible today. > > language, bday, bday-day, bday-month, > > bday-year, > > It's unfortunate that we don't have distinct input types for just a day, > just a month, or just a year. Why? (What's wrong with type=number, , and type=number respectively?) > exists, doesn't seem necessary to also have an > autocomplete value. As with the others, type=url just means "the data type is URL", it doesn't mean "the value is my home page". Let me know if you still disagree after having read the section I added to the spec and I'll reconsider. :-) > Also, should this not be a contact field? Do people have different home pages based on whether they're at home or at work or on their cellphone? > > > contact-type = "home", "work", "cell", or "fax" > > contact-field = one of: email, tel, tel-country-code, tel-national, > > tel-area-code, tel-local, tel-local-prefix, > > tel-local-suffix, tel-extension, impp > > I would suggest dropping the contact field values "email" and "tel" and > instead infer them from type. Please let me know if you still support this after reading the aforementioned section in the spec. (In particular, the spec talks explicitly about the "tel" case.) > So instead of you would just > say (and would not be able to say > , which would be an inferior > user experience when tel is given special behavior, or autocomplete="work tel">, which would be inconsistent). I'm a little wary about adding more magic here, these attributes are already pretty complicated. See the autocomplete section's algorithms and let me know if you still think we should do something along those lines. I
Re: [whatwg] register*Handler and Web Intents
On Thu, 2 Aug 2012, Henri Sivonen wrote: > > This is a severe violation of the Degrade Gracefully design principle. > Adopting your proposal would mean that pages that include the intent > element in head would parse significantly differently in browsers that > predate the HTML parsing algorithm or in browsers that implement it in > its current form. I believe that having the intent element break the > parser out of head in browsers that don't contain the parser differences > you implicitly propose would cause a lot of grief to Web authors and > would hinder the adoption of this feature. > > My concerns could be addressed in any of these three ways: > 1) Rename to > 2) Rename to > 3) Make have an end tag and make it placed in rather than > I'm pretty sure the short-term pain of introducing a new element would be far lower than the long-term pain of either of those three solutions. _Far_ lower. and already have tons of overloaded behaviours, but none of them come close to matching the set of attributes would need. So we'd be overloading them with yet another mechanism, further increasing author confusion for those elements forever. Having have an end tag is really ugly, since the element has no contents. We'd be forever requiring that authors add this dummy end tag that doesn't do anything, yet if forgotten causes all kinds of trouble in the DOM. Authors would try putting things inside it, further confusing matters. But now consider the short-term cost of adding an element to the head. All it does is make a few elements in the leak to the . The page still works fine in legacy UAs (none of the elements only work in the ). The works fine in new browsers, isn't confusing, doesn't have any random vestigial end tags. The only difference is that in legacy UAs, some elements happen to be in the instead of the , but that's hardly a big hardship -- and it's easy to work around, you just put the elements last in the , and then you can even use their position in the DOM as a way to detect support. I really am unconvinced that this is "a lot of grief". -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] alt="" and the exception
On Tue, 24 Jul 2012, Jukka K. Korpela wrote: > 2012-07-24 21:58, Ian Hickson wrote: > > On Tue, 24 Jul 2012, Edward O'Connor wrote: > > > > > > The spec currently disallows conformance checkers from reporting > > > elements without alt="" attributes as an error when > > name=generator> is present[1]. > > > > I've adjusted the text to make it clearer that validators can report > > the error in this case, just that they are discouraged from doing so. > > This is an improvement, but I think Edward O'Connor's points still > apply. Just saying that the page was generated by a generator has no > logical relationship to the issue of alt texts. Yes, it does. Only generators are in a position where they might have to include images for which they lack the ability to provide alt texts. > I think it would be better to keep the alt attribute always required but > recommend that conformance checkers have an option of switching off errors > related to this, due to situations where automatically generated markup > contains a large number of img elements without alt attributes. Such > situations can be *understandable* for practical reasons, but this does not > make the markup good and recommendable. On Wed, 25 Jul 2012, Henri Sivonen wrote: > > The big question is whether that would be enough to solve the problem of > generators generating bogus alts in order to pass validation. I predict > generator writers would want the generator output to pass validation > with the default settings and, therefore, what you suggest wouldn't fix > the problem that the spec is trying to fix. I agree with Henri here. On Wed, 25 Jul 2012, Jukka K. Korpela wrote: > > Quite possibly. We cannot prevent people from writing and selling buggy > software. A generator may produce valid code, or invalid code. We should > not change the definition of valid just to match some generator > behavior. The problem is that some generators -- e.g. software that converts word processor documents to HTML -- are in a position where they sometimes cannot possibly comply to the requirement. Image recognition and context analysis simply isn't good enough yet to handle this case. > After all, what's the point of using validation if you use a generator? People use validators to spot-check things all the time. > You would in effect be testing the generator, something that its vendor > should have done. We should not be concerned about helping generator > vendors to advertize their products as producing valid code (code that > passes validation) when they in fact produce code that violates > established good practices of HTML. Yes and no. It's unfortunate to force such vendors into a position of having to defend their one validation error when there's nothing they can do about it, and when the validation error in question is one they can so easily silence (without improving their conformance, and potentially harming the semantics at the same time). > According to normal accessibility principles, a generically informative > alt attribute is better than no alt attribute, which just says "here's > an image and we're not telling you anything about it, probably because a > lazy author didn't give the issue any thought". That's what the absence of an alt="" attribute means. > Even alt="unknown image" or alt="unknown image named foobar.jpg" is > better than lack of alt attribute (or alt=""). On the contrary; alt="unknown image" is equivalent to unknown image and would be fine alt="" text for an image of text that says "unknown image" or of an icon that represents an unknown image, but would be quite incorrect alt="" text for an image whose contents are unknown at the time of publication. On Wed, 25 Jul 2012, Leif Halvard Silli wrote: > > How about simply introducing a @generator attribute: > > In the past I have argued against this, on the basis that it is highly likely to be abused and actually make things worse. (The idea has been brought up numerous times over the past few years, in many forms.) However, a few years of experience with the "generator" idea have not led Henri and Mike (validator authors) to feel that the problem has been suitably addressed, and Mike is now implementing alternatives, so clearly it is time for me to revisit that. :-) We briefly brainstormed some ideas on #whatwg earlier tonight, and one name in particular that I think could work is the absurdly long This has several key characteristics that I think are good: - it's long, so people aren't going to want to type it out - it's long, so it will stick
Re: [whatwg] register*Handler and Web Intents
y then regard as hints > if no qualifying filter matches the intent invocation. I haven't added this to the proposal, but it does seem like a good idea. What do people think? Is it worth it? Traditionally, browsers and operating systems have handled the lack of a handler by offering known handlers, rather than relying on the caller to provide some. Given the ideal of declarative registration, one can imagine the browser redirecting to a search engine's list of handlers, for example. > Putting this in the HTML spec sounds like a great plan to us. Roger. > [wildcard handlers] > One exception would be for "save" type intents, where pretty much any > type can be dealt with. Another is where the handler is using say > or , and would like to specify accepted types in an open-ended > way. Interesting. For a "save"-type intent, which is really oblivious to the type, I guess we'd just allow the type to be null, meaning "any type". For features that are entirely dependent on client-side technologies, we could by convention say that a registration for image/* means "all the image types supported in , drawImage(), background-image, etc", and that video/* means "all the types supported in " and audio/* means "all the types supported in audio/*". (We should probably say that that's what the keywords mean for type=file, too.) > At the DAP meeting, we agreed to extend this system to include > string-literal types, which provides a way to do good integration with > microdata types. There we expect to do exact string matching, and it is > true the eliminating wildcard types would bring these two type > namespaces a bit closer. MIME is complex enough that it would still have > to be treated separately, however. (Parameters and all that.) I'm not really sure I follow here. Could you elaborate? On Thu, 24 May 2012, Greg Billock wrote: > > Some more concordance moves to make them more like different aspects of > the same feature: > > * In registerContentHandler, "t" can be a space-separated list of MIME > types for registerContentHandler. Do we need to support a space-separated list at all? When will the list be so long that it really makes sense to add that feature rather than just having three registrations back-to-back? (I have omittd a number of e-mails from this reply that gave suggestions that seemed reasonable and that have therefore been incorporated into the proposal above.) If nobody finds any egregious problems with the proposal above, I'll start speccing it as part of a rewrite of the register*Handler() section. (That section needs a rewrite into more imperative language anyway.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
On Wed, 25 Jul 2012, Melvin Carvalho wrote: > > Just so that it's possible to understand how to name the two new > branches correctly, can you confirm that the W3C branch is now called > "HTML5" and the WHATWG branch is named 'HTML Living Standard'. > Is this the long term project name, or just a working title? The WHATWG spec is just called "HTML", "Living Standard" is what it is. As we've gone through half a dozen names already for this spec (XForms Basic, Web Forms 2.0, Web Applications 1.0, HTML 5, HTML5, Web Applications 1.0 again, and now HTML), I don't intend to change it again, but who knows. :-) As of the last time the W3C equivalent spec was updated, it was titled "HTML5", but you'd have to ask the W3C what their plans are. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
To reiterate the statement I made in the original post on this thread: If you have any questions, I encourage you to e-mail me privately or ask on the IRC channel (#whatwg on Freenode); process-related discussion is discouraged on this mailing list so that we can maintain a high technical signal to noise ratio. You can also cc an archive mailing list, e.g. the www-arch...@w3.org mailing list, or cc me on a public post on a system such as Google+ or e-mail me a link to your blog post. Answers to any frequent questions about process issues will be added to the FAQ (something that you can do directly or which you can wait for someone else such as me to do). This mailing list (wha...@whatwg.org) is specifically for technical discussions and not for process discussions. Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] alt="" and the exception
On Tue, 24 Jul 2012, Edward O'Connor wrote: > > The spec currently disallows conformance checkers from reporting > elements without alt="" attributes as an error when name=generator> is present[1]. I've adjusted the text to make it clearer that validators can report the error in this case, just that they are discouraged from doing so. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comments about the track element
[only replied on the whatwg list; please if possible avoid cross-posting as it tends to fracture threads when people only on one list and not the other reply] On Tue, 24 Jul 2012, Cyril Concolato wrote: > > During the ongoing SVG F2F meeting, the SVG WG discussed the use case of > displaying SVG graphics on top of a video, in a synchronous manner. > > The SVG WG believes that for such use case, it is necessary to indicate > to the browser that the SVG and video content should stay synchronized > (no matter what happens to the video playback), and to let the browser > handle the synchronization internally. The SVG WG resolved to include > such indication as part of the Web Animation specification, for instance > using the HTML mediagroup attribute or the MediaController API. > > However, the SVG WG thinks it would also be interesting to leverage the > native UI controls of the video element to select (or deactivate) the > display of the SVG content on top of the video, in a similar manner to a > subtitle track. Obviously, the HTML 5 track element would be a suitable > option for that. However, currently it only allows text tracks. So, the > SVG WG would like HTML to allow the track element's URL to identify an > SVG resource, and in that case the track kind would be 'graphics'. There > would be a need to define how the graphics are displayed on top of the > video, for instance reusing the viewport/viewbox negotiation phase. > There would also be a need to make a more generic Track API or to > replace the TextTrack API by the SVG API when the track is of kind > 'graphics'. My understanding is that the expected way to solve this previously was using SMIL, putting the video in the SVG itself. That seems to make more sense that having the SVG layered on top of an HTML video. Why is this no longer a viable solution? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] A mechanism to improve form autofill
ogin-field autocomplete was desired, then > perhaps a mixed type would work too: > > > > How about merging autocompletetype with autocomplete then? > > It looks sensible to me: > > Yeah, using autocomplete="" in this way makes a lot of sense I think. Studying the forms in the listing cited above, it seems that fields fall into these categories: Separate forms all found in the same , e.g. for pages that contain multiple products each with their own set of fields, only one product of which is shown at a time. At a high level, the use agent should treat each of these as a separate for autofill purposes. Each of these can have information for different people or facets of people: - shipping information - billing information - generic user information (e.g. when it's not a shipping order form) Each of these sections can then have subinformation: - name (and its subfields, such as "honorific-prefix", "nickname", etc) - "organisation" name, the user's "organisation-title" - physical address (and its subfields, such as "city", "state", etc) - contact information category, e.g. "home", "work", "cell", "fax" - each of which has subinformation such as "email", "tel" (and their subfields, such as "country-code") - credit card details (and subfields such as "name", "exp" etc) - personal information (such as "bday", "url", "photo") So we could define the autocomplete="" field's value as follows: "on", "off", or: [section] [subsection] [generic-field | [contact-type] contact-field] ...where section = high-level section name; author-defined string starting with the prefix "section-" subsection= "shipping" or "billing" generic-field = one of: name, honorific-prefix, given-name, additional-name, family-name, honorific-suffix, nickname, organisation-title, organisation, street-address, address-line1, address-line2, address-line3, locality, region, country, postal-code, cc-name, cc-given-name, cc-additional-name, cc-family-name, cc-number, cc-exp, cc-exp-month, cc-exp-year, cc-csc, language, bday, bday-day, bday-month, bday-year, sex, url, photo contact-type = "home", "work", "cell", or "fax" contact-field = one of: email, tel, tel-country-code, tel-national, tel-area-code, tel-local, tel-local-prefix, tel-local-suffix, tel-extension, impp ...with some conformance rules, so that each section/subsection and section/subsection/context-type group has: - either up to one "name" or up to one of each of "honorific-prefix", "given-name", "additional-name", "family-name", "honorific-suffix" - up to one "organisation-title" - up to one "organisation" - either one "street-address", or one "address-line1" - up to one "address-line2", but only if there is an "address-line1" - up to one "address-line3", but only if there is an "address-line2" - up to one of each of "locality", "region", "country", "postal-code" - either up to one "cc-name" or up to one of each of "cc-given-name", "cc-additional-name", "cc-family-name" - up to one "cc-number" - either up to one "cc-exp" or up to one each of "cc-exp-month" and "cc-exp-year" - up to one "cc-csc" - up to one "language" - either up to one "bday" or up to one each of "bday-day", "bday-month", and "bday-year" - up to one "sex" - up to one "url" - up to one "photo" - up to one "email" - either up to one "tel" or up to one each of "tel-country-code" and "tel-national" - if there is no "tel" and no "tel-national", up to one each of: "tel-area-code" and "tel-local" - if there is no "tel", no "tel-national", and no "tel-local": up to one each of "tel-local-prefix" and "tel-local-suffix" - up to one "tel-extension" - up to one "impp" The UA conformance criteria would be pretty minimal: for each input control with an autocomplete value that matches the above long forms, try to determine a value that matches the description of that value (the spec would have prose and a table describing what the values mean), and optionally offer to set the control to that value. The values must pass all the form control validation stuff, so e.g. if a control has maxlength=1 and autocomplete="shipping additional-name" then the only sensible value to offer is the middle initial of the person to which the user is intending to ship the product. The documentation in the spec would recommend particular input types for each field, and discourage the use of the decomposed forms, but there would not be any conformance criteria there. Are there any common fields missing from the list above? Any categories other than "billing" and "shipping" that should be listed? Anything other than "work", "home", and "fax"? Should it be "work-fax" and "home-fax"? Should we instead have the fax-* fields to parallel the "tel-*" fields, so you can say you have a cell fax and so you can't say you have a fax e-mail or fax Jabber? Does it make sense to have home and cell e-mail accounts separately specifiable? Should we disallow addresses and contact details without the "shipping"/"billing" labels? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 's position property
On Fri, 20 Jul 2012, Matt Falkenhagen wrote: > > I'm trying to implement the positioning of in WebKit and am > looking at the UA style sheet for dialog [1]. Is there a reason > position:absolute is used instead of fixed? If it was fixed, and the dialog was taller than the window, there would be no way to view the whole dialog. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification
hat are assigned to nobody today will in due course presumably be reassigned to whoever becomes the editor of the W3C's HTML5 specifications. This effort does not affect bugs filed in the future; I am still working with the chairs of the HTML working group to work out what our long-term plan should be for this going forward. The old "other Hixie drafts" component is now gone. The changes described above are unrelated to the change announced in April regarding the WHATWG's adoption of the W3C Community Group mechanism, but together they mean we are now independent of the W3C HTML Working Group again, while still maintaining a working relationship with the W3C. [4] My hope is that the net effect of all this will be that work on the HTML Living Standard will accelerate again, resuming the pace it had before we started working with the W3C working group. If you have any questions, I encourage you to e-mail me privately or ask on the IRC channel (#whatwg on Freenode); process-related discussion is discouraged on this mailing list so that we can maintain a high technical signal to noise ratio. -- Footnotes -- [1] or a few months after we find them... I'm about 6 months behind right now. Sorry about that. Working on it! [2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0204.html [3] Actually I had bookmarklets for closing the bugs as "Accepted" and "Rejected" which, for bugs in the W3C HTML WG components, used the boilerplate required of me by the HTML working group process, and for bugs in the "other" component skipped the boilerplate. The HTMLWG only applied its process to bugs in their components. [4] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Apr/0240.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Input modes: Please help me with some research!
One of the features that I'm looking at specifying (again) is a mechanism for authors to help user agents pick the most appropriate input mode. For some cases this is easy; for example, user agents can know that an field should have a numeric keyboard. However, in some other cases it's not at all obvious; e.g. you want a numeric keyboard for credit card fields, which are type=text. To do this properly, I need to have a list of all the possible keyboards we should expose. Two things would be helpful to that end: - Screenshots of keyboards - Details of APIs in existing platforms that control input modes. I've added some screenshots of keyboards from Android to this wiki page: http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control If anyone can help out by adding more screenshots from other platforms, especially for non-English input languages, or by providing links to documentation for input mode APIs on operating systems that support them that would be great. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Canvas hit region feedback
On Thu, 5 Jul 2012, Edward O'Connor wrote: > > Currently, there are only two ways to invoke the "clear regions that > cover the pixels" algorithm: by calling either addHitRegion() or > clearRect(). Authors should be able to explicitly remove a hit region as > well, with a removeHitRegion(id) method. > > Consider a region of a canvas which the author would like to toggle > between clickable and non-clickable states without drawing. Maybe > they're indicating clickability by drawing a different outline around > the region without actually redrawing the region itself, or perhaps > there is no visible indication that the region's clickability is > changing. Such an author should be able to straightforwardly achieve > this without redrawing the region (as clearRect would require) and > without installing a dummy hit region (as addHitRegion would require). Done. On Thu, 5 Jul 2012, Charles Pritchard wrote: > > There's also just removing the element from the DOM. Yes, I'd like a > removeHitRegion(Element) feature; though I can skate by with the empty > addHitRegion method. I don't follow this proposal. > I've not seen a response from you regarding the issues that Richard and > Steve have brought up around the lightweight nodes feature-proposal. It > seems relevant to the method signature of removeHitRegion. I checked the list but didn't see any recent relevant e-mails from anyone named Richard or Steve. If they filed bugs, I hope to get to those soon; I've been focusing on e-mail for a while to get the e-mail pile under control after having neglected it for too long. Re: using backing bitmaps for hit testing: On Fri, 6 Jul 2012, Rik Cabanier wrote: > > Yeah, this is the standard way of doing hit-testing. However, one > important use case is that this can be done with nested canvas elements. > Most (if not all) games, will use off-screen canvas elements to draw > elements which can then be reused. > > The programmer will creates hit test canvas elements which are then > composited similarly to the off-screen canvases. > > It seems that the additions that Ian made does not cover this use case > unless there's a way to extract the hit regions from a canvas and then > apply/remove them (with a possible matrix manipulation) to/from another > canvas. That's an interesting idea. I haven't added this yet, but it seems like something we should definitely keep in mind; if it turns out that the hit region API is popular, it would definitely be a logical next step. On Sat, 7 Jul 2012, Dean Jackson wrote: > > We're aware of this technique, but it has a couple of obvious issues: > > 1. It requires us to create a duplicate canvas, possibly using many MB > of RAM. It's generally going to be less memory to keep a list of > geometric regions. And performance won't be terrible if you implement > some spatial hashing, etc. > > 2. It doesn't allow for sub pixel testing. In your algorithm above, only > one region can be at a pixel (which also means it isn't our standard > drawing code with anti-aliasing). Consider a zoomed canvas, where we > might want more accurate hit testing. Certainly implementations are welcome to use a hit region list with fine paths, rather than pixels, so long as the effect is equivalent. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Tue, 20 Mar 2012, Edward O'Connor wrote:
>
> Unfortunately, lots of content (especially content which calls
> {create,get,put}ImageData methods) assumes that the 's backing
> store pixels correspond 1:1 to CSS pixels, even though the spec has been
> written to allow for the backing store to be at a different scale
> factor.
I've fixed the text so that those methods now always return 96dpi data.
> I'd like to propose the addition of a backingStorePixelRatio property to
> the 2D context object. Just as window.devicePixelRatio expresses the
> ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would
> express the ratio of backing store pixels to CSS pixels. This allows
> developers to easily branch to handle different backing store scale
> factors.
I've added window.screen.canvasResolution which returns the resolution
that is being used for 2D canvases created during the current task.
> Additionally, I think the existing {create,get,put}ImageData API needs
> to be defined to be in terms of CSS pixels, since that's what existing
> content assumes.
Done.
> I propose the addition of a new set of methods for working directly with
> backing store image data. (New methods are easier to feature detect than
> adding optional arguments to the existing methods.) At the moment I'm
> calling these {create,get,put}ImageDataHD, but I'm not wedded to the
> names. (Nor do I want to bikeshed them.)
Done.
I've also added toDataURLHD and toBlobHD.
On Tue, 20 Mar 2012, James Robinson wrote:
>
> If we are adding new APIs for manipulating the backing directly, can we
> make them asynchronous? This would allow for many optimization
> opportunities that are currently difficult or impossible.
I haven't done this, because it would make the API rather weird. But I am
happy to do it if people think the API weirdness is a cost worth paying.
Note that technically getImageData() doesn't have to block -- it's array
access on ImageData that has to block. It would be possible to implement
getImageData() in such a way that the ImageData object is lazily filled.
You'd end up blocking later if the author really needed the data, but it's
possible to write code that doesn't block (though you wouldn't necessarily
know how long to wait, I guess).
On Tue, 20 Mar 2012, Boris Zbarsky wrote:
> On 3/20/12 6:36 PM, Glenn Maynard wrote:
> > The drawing calls that happen after would need to be buffered (or
> > otherwise flush the queue, akin to calling glFinish), so the
> > operations still happen in order.
>
> The former seems like it could get pretty expensive and the latter would
> negate the benefits of making it async, imo.
Having the operations not occur in order would make the API quite
difficult to use, so if that's not an option, I don't think it's worth it.
On Wed, 21 Mar 2012, Maciej Stachowiak wrote:
> On Mar 20, 2012, at 12:00 PM, James Robinson wrote:
> >
> > If we are adding new APIs for manipulating the backing directly, can
> > we make them asynchronous? This would allow for many optimization
> > opportunities that are currently difficult or impossible.
>
> Neat idea to offer async backing store access. I'm not sure that we
> should tie this to backing store access at true backing store resolution
> vs at CSS pixel nominal resolution, because it will significantly raise
> the barrier to authors recoding their existing apps to take full
> advantage of higher resolutions. With Ted's proposal, all they would
> have to do is use the HD versions of calls and change their loops to
> read the bounds from the ImageData object instead of assuming. If we
> also forced the new calls to be async, then more extensive changes would
> be required.
>
> I hear you on the benefits of async calls, but I think it would be
> better to sell authors on their benefits separately.
I think it depends how strong the benefits are. In this particular case, I
tend to agree that the benefits aren't really worth tying them together,
and possibly not worth providing the async model as a separate API at all.
Maybe we could have an attribute on ImageData that says whether an array
index read would have to block on getting the data or whether it's ready,
maybe coupled with an event that says when it's ready?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Suggest making and valid in
On Mon, 16 Jul 2012, Jukka K. Korpela wrote: > 2012-07-16 5:36, Ian Yang wrote: > > > > Imo, means the order of the items is unimportant, not browsers > > can render the items in any order. > > But if the order is unimportant, there still _is_ an order. The specification even mentions that the order can be specific and intentional; e.g. alphabetical. The spec doesn't say that there is no order, merely that the order is not important. > Being unordered would be something else. Something essentially impossible in the linear medium that is digital content. :-) > And what would it matter to indicate the order as important if you only > do that in markup, without affecting rendering, search engines, etc., at > all? It can affect search engines. In particular, for example, Google will extract items from lists in Web pages and display them in the search engine results snippets. If the list's order is unimportant, it can reorder the items to give the most relevant ones first. If the order _is_ important, it might make more sense for it to only show the first few. > The only reason for this "unordered" list idea (a list is by definition > unordered; a set, or a multiset, is not) is the willingness to keep > and in HTML (it would be very impractical to omit one of them) > without admitting that they were introduced, and are being used, simply > for bulleted and numbered lists. So this resembles the confusing play > with words regarding and . No, these are quite different. The and that were introduced in the contemporary version of the spec have entirely different semantics as the obsolete ones from the HTML4 days. They were only introduced after strong use cases were presented, and they happen to use the same element names because that allows us to leverage existing implementations. In the case of and they were kept more or less as defined in HTML4 (though with better wording and examples). To be honest I don't think we ever really studied whether or not they should be included; given their broad use and relatively minimal negatives, there was no reason to. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Suggest making and valid in
oses, in the dawn of HTML, were that and > correspond to numbered and bulleted lists, respectively, reflecting two > very common concepts in word processors. This is how they have been > used, though some authors have started overusing for thinks like > lists of links even when they specifically don't want them to appear as > bulleted. Certainly that is, to a first approximation, a good way of thinking of the difference between the two. Of course, in many contexts there are no bullets or numbers, so this simplification is not the whole story. For example, when reading a list, even an unordered list, using speech synthesis, it may be useful for navigation purposes to have all lists be numbered. This does not mean there is no difference between and , as the examples in the spec illustrate. > Even W3C specifications, in their markup, switch to in the midst of > hierarchy when they want bullets and not numbers. W3C specifications are hardly what I would refer to as the epitome of good Web design, so I'm not sure I'd draw any conclusions from that! > HTML5 tries to stick to the theoretical idea of "ordered" vs. > "unordered" list, but it does not really change anything, and it is not > supposed to change anything - any will still be rendered in the > order written. Not necessarily. That depends on the UA. > More on this: > http://www.cs.tut.fi/~jkorpela/html/ul-ol.html The example in that document, from the old HTML4 specification, is a perfect example of incorrect usage of . In general, I would recommend referring to the contemporary specification for more precise information on the elements' semantics and usage. On Sun, 15 Jul 2012, Jukka K. Korpela wrote: > 2012-07-15 17:40, Ian Yang wrote: > > > > As a coder, personally I don't care how browsers render them by > > default. > > You should. Check out the Usual CSS Caveats. On the contrary. Ian is correct to rely on the meaning of the language rather than its default rendering in one user agent or another. On Mon, 16 Jul 2012, Ian Yang wrote: > > Sorry, I still don't get it. means unordered list; means > ordered list. They are quite different, aren't they? They are indeed quite different. > Imo, means the order of the items is unimportant, not browsers can > render the items in any order. > > If there were a browser which wants to render the items of in any > order, okay, it may do that. Anyway, that's not my main concern. That is an appropriate use of HTML. :-) On Sat, 14 Jul 2012, Ian Yang wrote: > > Thanks for the info about the spec saying in the order of the list > of groups *may* be significant. However, what it says means a > itself is unable to tell whether its contents are unordered or ordered, > and we have to judge that by ourselves. Well, what it means is that a user agent can't randomly reorder a 's contents, as that would violate the rule that its rendering must faithfully represent the page's semantics. (The spec relies on this in several places to mark up English-prose equivalents of "switch statements" in its algorithms, for example.) > Comparing to and which themselves are able to tell whether > their contents are unordered and ordered, the itself being unable > to do that is, imho, disappointing. It's something we could add, but it's not clear that there's a compelling need for it. What is the use case for knowing that a 's contents can be arbitrarily reordered? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Why do HTML*Collection's nameItem need to return 5 different objects?
On Fri, 13 Jul 2012, Ryosuke Niwa wrote: > > According to > http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#htmlpropertiescollection > > *HTMLCollection* returns the first element. This is for compat in the default case, I believe. > *HTMLAllCollection* returns the first element or another HTMLAllCollection > if there are multiple elements This is needed for IE compat. > *HTMLFormControlsCollection* returns the first element or RadioNodeList if > there are multiple elements This is needed to support the radio button value feature. > *HTMLOptionsCollection* returns the first element or live NodeList if there > are multiple elements This is for compat, I believe. (We don't want to return just a node if there are many matching.) > *HTMLPropertiesCollection* returns PropertyNodeList This is to support the value features for microdata. > Can those 3 classes somehow return the same object? FWIW, WebKit has > always returned a static node list. WebKit doesn't support the microdata and radio button features, presumably, and is presumably less than perfectly compatible with the Web for the others. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Device proximity and light events
On Fri, 4 May 2012, Doug Turner wrote: > > I have added two new events to Firefox which allow web apps to detect > light and proximity changes. > > http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/ > http://dougturner.wordpress.com/2012/03/26/device-light-sensor/ I spoke to Doug about this on IRC and for now I'm not going to spec this in the HTML spec. It would probably be good for these events to be combined with the Geo and device orientation events and all specced together, but I'll leave that up to whoever specs them. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we make checkboxes readonly?
On Wed, 11 Jul 2012, Markus Ernst wrote: > Am 11.07.2012 00:59 schrieb Ian Hickson: > > On Fri, 4 May 2012, Tab Atkins Jr. wrote: > > > On Wed, May 2, 2012 at 3:57 PM, Ian Hickson wrote: > > > > On Wed, 6 Apr 2011, Tab Atkins Jr. wrote: > > > > > An app may dynamically set inputs or groups of inputs to readonly > > > > > based on app state. When you submit, though, it's impossible to > > > > > tell (without hacks) whether a checkbox was checked-but-disabled or > > > > > just unchecked. Handling the form data is *much* easier if you just > > > > > get all the data, regardless of whether, as a UI convenience, your > > > > > app temporarily set some of the inputs to readonly. > > > > > > > > That's a use case for submitting disabled check boxes, not for > > > > read-only checkboxes, IMHO. (The same could be said for disabled > > > > text controls.) > > > > > > That's more-or-less what @readonly does - the input becomes > > > "disabled" but still submits. > > > > That's part of what it does, but not the main thing it does. It's > > mainly a UI affordance, which doesn't apply to check boxes. > > Given that there are valid use cases for submitting values of elements > that have a disabled resp. readonly behaviour in the UI: Would it do any > _harm_ to allow @readonly to checkboxes and radio buttons? I assume this > would be easy and possible without breaking existing content. Submitting > disabled elements, OTOH, looks to me like an impossible change, as it > would likely break existing content. Just making readonly="" on checkboxes be a synonym for disabled="" (but with different submission behaviour) would be an abuse of the attribute, IMHO, since readonly="" doesn't mean disabled, it means read-only, which is a concept that only applies to text fields. The only reason we'd want to use readonly="" rather than make up some new feature is if it had good graceful degradation, but it doesn't (it wouldn't be disabled in old UAs). If we want to make it possible to submit disabled controls, we should just provide that feature explicitly, e.g. an attribute on that causes disabled controls to be submitted. But with form submission slowly being replaced by JavaScript-mediated in-place "AJAX" UI, and given that the server typically already has the disabled data since it sent it to the user and the user isn't allowed to change it, and given that servers can't trust the client not to have changed the data so has to check it anyway, and given that it's possible to work around this issue already using type=hidden without much difficulty, I don't really see much of a compelling reason to add this feature at this time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Can we make checkboxes readonly?
On Thu, 3 May 2012, Shaun Moss wrote: > > An obvious use case for readonly checkboxes came up a few weeks ago when > I made this page: http://marssociety.org.au/membership > > The checklist at the bottom I could have made more simply/cheaply with > readonly checkboxes. However I had to use images. Those aren't check boxes, so it seems entirely correct that you not use the element for them. It would be like using for the cells in the second column of that table, or for the cells in the first column. On Fri, 4 May 2012, Tab Atkins Jr. wrote: > On Wed, May 2, 2012 at 3:57 PM, Ian Hickson wrote: > > On Wed, 6 Apr 2011, Tab Atkins Jr. wrote: > >> An app may dynamically set inputs or groups of inputs to readonly > >> based on app state. When you submit, though, it's impossible to > >> tell (without hacks) whether a checkbox was checked-but-disabled or > >> just unchecked. Handling the form data is *much* easier if you just > >> get all the data, regardless of whether, as a UI convenience, your > >> app temporarily set some of the inputs to readonly. > > > > That's a use case for submitting disabled check boxes, not for > > read-only checkboxes, IMHO. (The same could be said for disabled text > > controls.) > > That's more-or-less what @readonly does - the input becomes "disabled" > but still submits. That's part of what it does, but not the main thing it does. It's mainly a UI affordance, which doesn't apply to check boxes. -- 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 7:17 PM, Ian Hickson wrote:
> > 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.
>
> Let me rephrase, I simply expect modern DOM APIs to return something
> useful.
I don't think a function should return something just for the sake of
returning something. I agree that when there is something useful to return
(something that the caller doesn't already have at hand, in particular,
and might be able to make use of) that it makes sense to return it.
> > I understand that this is mostly a matter of taste in API design, but
> > IMHO that's an anti-pattern.
>
> If you're writing and designing specifications that will be implemented
> in JavaScript, then you should design them _for_ JavaScript. Section 15
> of EcmaScript specifies more then enough "prior art" that supports my
> statement above.
There's plenty of prior art in the Web platform to support pretty much any
pet design philosophy.
> > It encourages poor style;
>
> 60% of the JavaScript written on the web disagrees.
Disagrees with what? You really think that 60% of the Web is written in
good style?
> > it discourages functional programming patterns, instead favouring
> > state mutation patterns;
>
> JavaScript is a multi-paradigm language, leave your design hangups at
> the door.
...says the guy arguing for a particular paradigm. :-)
> > it makes APIs harder to extend;
>
> This is just outright false, considering JavaScript is probably the most
> extendable and historically extended language at the API level.
If you have a return value, you can't change it. If you don't, you at
least have the chance that you might be able to introduce one. So yes, it
makes APIs harder to extend.
> > it makes APIs that do have useful return values inconsistent with
> > other APIs;
>
> elem.classList.add("foo") returns "undefined". That's hardly what I
> would consider a "useful return value".
Right. But elem.classList.contains() returns a boolean, and
elem.classList.item() returns a string. So they can't be consistent with
the APIs that return self.
> Returning the element's classList instance makes an incredible amount of
> rational sense.
It's an aesthetic choice with some advantages and some disadvantages. I
don't think it's an obvious choice, by any means.
> > it is, in fact, a layering violation: it attempts to shoehorn what
> > should be a language design feature into the API layer.
>
> Much like the DOM and its weird C++ and Java influences.
We're trying to reduce them, not
> Is this group aiming to define APIs that developers will always paper
> over with abstractions, guaranteeing all app code needs a good 50k just
> to provide a decent API?
There are certainly design decisions where one might wonder whether I am
just actively trying to make the Web bad (localStorage comes to mind). But
when it comes to chaining vs not chaining, it's just not the same. I
understand that some people prefer:
a.foo().bar().baz();
...rather than:
a.foo();
a.bar();
a.baz();
...but if an author cares so much about the difference that they'll write
50,000 lines of code (!) to abstract out the difference (!) then I think
they might have their priorities set up wrong.
On Thu, 3 May 2012, Jake Verbaten wrote:
>
> Choosing some mechanism to add multiple classes at once is useful, whether
> that's making add have an arbitary arity, allow it to take an array, allow
> it to take a space seperated string or allowing add calls to be chained.
>
> My personal vote is for arity.
This API is now in the DOM Core specs, so I'll let the DOM Core editors
respond to this.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for readyState behavior
ome and IE9!) > Delta from the spec: No delta. Agreed. > 8) When readyState changes, a "readystatechange" should be fired > (synchronously immediately after readyState changed) > Rationale: >* Seems illogical not to. >* Already true in Chrome and Firefox, so it seems browsers can > get away with doing the logical thing. > Delta from the spec: No delta. Agreed. > 9) Never fire "readystatechange" so that the old and new readyState > are the same. > Rationale: >* Logic. >* All deviations from this rule look like browser-specific bugs. > Delta from the spec: No delta. Agreed. > 10) XSLT error pages don't count as aborts but instead as non-aborted > loads of the error page. > Rationale: >* Makes parent pages less confused about events they are waiting. >* Already true except for bugs in Firefox which is the only > browser with XSLT error pages. > Delta from the spec: Make explicit in spec. I haven't defined this because to define this I'd have to define a ton of infrastructure that explains how XSLT works in the first place, and I'm still waiting for the XSLT community to write the tests that demonstrate what the requirements should be: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689 > Aside: Might make sense to spec DOMFrameContentLoaded. Firefox and > Opera support it. I haven't specced this yet. Is there interest from other browsers to support it? I hesitate to make this part of the spec any more complex... -- 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, 9 Jul 2012, Boris Zbarsky wrote: > On 7/9/12 8:39 PM, Ian Hickson wrote: > > Surely that's going to set the attribute regardless of whether the > > attribute is nullable or whatnot. > > Well, that depends on how reflecting "DOMString?" attributes are > defined. Making setting null call removeAttribute would work much like > boolean attributes work. That's an interesting idea, but it seems to me to be a bit late to be making such a fundamental change to the HTML DOM API. I mean, so far no attributes work that way (except in WebKit, apparently?); boolean attributes are the only ones where there's any way to remove the attribute by setting a value, more or less. It's not the first attribute where the empty string means something different than the attribute being omitted. > > > More importantly, > > > > > >myOtherFrame.sandbox = myFrame.sandbox; > > > > > > doesn't have weird surprising behavior if the attribute is something > > > whose value sanely distinguishes between the various possible > > > sandbox values. > > > > I'm not sure I follow. > > The point is that 'not set' and 'empty string' don't mean the same thing > for @sandbox, and ideally the DOM reflection would preserve the > distinction. Since it doesn't for any other attributes that take a string but where empty string and absence are different, why is it suddenly an issue specifically with this attribute? > > I think remaining consistent with other non-boolean attributes, and > > thus having the setter always set the attribute, is fine. > > And I think it's a footgun. No more so, I'd wager, than being inconsistent with the other attributes. I think the situation would be different if you were asking about changing the behaviour of all content attributes rather than one specific one. That's what Simon is arguing for here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17283 I'm not sure that makes sense either, but it's more plausible, IMHO, especially given that at least one UA apparently already does it. If Gecko also changed in this manner it would make the decision a lot easier. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] sandboxed documents and cookies
On Fri, 15 Jun 2012, Ian Melven wrote: > > in https://bugzilla.mozilla.org/show_bug.cgi?id=341604#c180, David-Sarah > Hopwood makes a few points about cookies in sandboxed documents : > > "Ugh, that's mandating an information leak about whether the document > has cookies. Maybe a minor leak, but I don't understand why it should > exist: if allow-same-origin is not set, then the clear intent is that no > information about cookies should be available." > > "Oh, and another reason not to do it that way is that it's a testing > hazard for web developers. They test when there are no cookies, it > works, then the parent document adds cookies (which has no reason to > make any difference), and it breaks because the code in the sandboxed > document didn't expect the exception." > > The spec (http://dev.w3.org/html5/spec/dom.html#sandboxCookies) says : > "On getting, if the document is a cookie-free Document object, then the > user agent must return the empty string. Otherwise, if the Document's > origin is not a scheme/host/port tuple, the user agent must throw a > SecurityError exception." > > IE 10, Chrome and the patches I am working on for Firefox all throw a > SecurityError even if no cookies are set - i agree that this seems like > the correct behaviour. I believe you have a mistaken understanding of what "cookie-free Document" meant. I've renamed the term to avoid the confusing interpretation. It's now called a "cookie-averse Document". Please let me know if you still think the logic described in the specification is incorrect. Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Additional attribute value for iframe sandbox
On Mon, 30 Apr 2012, Tim Streater wrote: > > I'd like to request that it be possible for links in sandboxed iframes, > when clicked, to open in a new window. My reading of the documentation > suggests that in a sandboxed iframe, links are disabled except that > "allow-top-navigation" permits the equivalent of "target='_top'". In > effect, I'd like a new value that permits "target='_blank'". Testing > today tells me that in fact in Safari 5.1.5 at least, a sandboxed iframe > does not interfere in any way with links. > > My use case is this. My application, a mail client, receives html emails > and uses an iframe to display them. A good example of such a mail can be > seen here: > > http://www.newscientist.com/data/projects/newsletter/newsletter20120430rwau.html > > (When I receive it, the recipient's email address is in the bottom part > of the page rather than #emailaddr#.) This is an example of a trusted > email which has links. At present, my application strips out scripts as > a primitive security measure, but I'd rather use a sandboxed iframe if > possible. However, a user will expect to be able to click on a link in > such an email and have a new window opened, separate from the email > client. Hence my request for a new value for the sandbox attribute. On Mon, 30 Apr 2012, Charles Pritchard wrote: > On 4/30/12 2:04 PM, Tim Streater wrote: > > On 30 Apr 2012 at 21:17, Charles Pritchard wrote: > > > They've got an allow-popup in IE and I think WebKit. It's just a > > > little slow going in getting it firmly out there. > > > > Yes, I saw that as I worked on through the archive. But they want to > > enforce the same restrictions on the newly-opened window as the iframe > > had. I'd prefer no restrictions, but also no connection back from the > > opened window to its parent. IOW, just as if one had opened a new > > browser window and typed the URI in manually. > > The about:blank + hack is no fun; the thing used to break > out of origin in webkit. > > I'd hoped iframe sandbox had that solved. Well, nothing stops the user from opening any links the user wants to open wherever the user wants to open them. All sandbox="" does is prevent the page from automatically opening pages. I'm not 100% clear on what you're trying to block with sandbox if that's not sufficient. Maybe if you could describe your threat model in more detail it would be clearer? -- 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:19 PM, Ian Hickson wrote: > > Changing it to a string doesn't affect that, though, does it? > > Well, changing to a nullable string does affect it because doing > something like this: > > myFrame.sandbox = myFrame.sandbox; > > is a no-op, as by all sane rights it should be Surely that's going to set the attribute regardless of whether the attribute is nullable or whatnot. I mean, this always sets the attribute even if the attribute wasn't previously set: myElement.title = myElement.title > More importantly, > > myOtherFrame.sandbox = myFrame.sandbox; > > doesn't have weird surprising behavior if the attribute is something > whose value sanely distinguishes between the various possible sandbox > values. I'm not sure I follow. > > 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. > > Would we also make the attribute readonly, then, and require that it be > set via the token list? Otherwise, it seems like the snippets above > would still have pretty unexpected behavior. But even then they might, > since sets of readonly props are just silently ignored. :( I think remaining consistent with other non-boolean attributes, and thus having the setter always set the attribute, is fine. On Thu, 29 Mar 2012, Adam Barth wrote: > > I guess I don't see much value in using DOMSettableTokenList for the > sandbox property. I don't expect folks to mutate the property much. > They're just likely to set it to a constant and be done with it. The > situation is very different for a property like className, where there's > a strong use case for mutating. On Fri, 30 Mar 2012, Ian Melven wrote: > > I agree that it's pretty likely folks won't be mutating this property > very often - the HTML5 spec actually recommends against messing with the > sandbox attribute dynamically at all: > > "Generally speaking, dynamically removing or changing the sandbox > attribute is ill-advised, because it can make it quite hard to reason > about what will be allowed and what will not." On Fri, 30 Mar 2012, Adam Barth wrote: > > IMHO, it's better if the sandbox property behaves like other properties > rather than being magically different. In these cases, the result is > more sandboxing than you might expect rather than less, which is > probably fine. On Fri, 30 Mar 2012, Jonas Sicking wrote: > > I think there's a lot of logic to that. One thing that I think we should > do as part of that is to drop the DOMSettableTokenList. By far more > "mapped attributes" are normal DOMStrings. On Sat, 31 Mar 2012, Anne van Kesteren wrote: > > Such as? I thought the whole point was to do away with that so that > authors do not have to implement the parsing logic anymore. Upon reflection, I haven't changed anything here. I don't see much value in making an exception to 'sandbox' here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sublties with seamless navigation
On Tue, 10 Apr 2012, Adam Barth wrote: > > Consider the following requirement for seamless iframes: > > http://www.whatwg.org/specs/web-apps/current-work/#seamlessLinks > > [[ > If the source browsing context is the same as the browsing context > being navigated, and this browsing context has its seamless browsing > context flag set, and the browsing context being navigated was not > chosen using an explicit self-navigation override, then find the > nearest ancestor browsing context that does not have its seamless > browsing context flag set, and continue these steps as if that > browsing context was the one that was going to be navigated instead. > ]] > > However, that requirement seems to be a bit too agressive. For example, > setting the "src" attribute on the iframe element loads the document in > the iframe using the Navigate keyword. Uh, yeah. Oops. Fixed. > Should we be more explicit in > <http://www.whatwg.org/specs/web-apps/current-work/#dom-iframe-src> > about what the source browsing context is? The more relevant part is: http://www.whatwg.org/specs/web-apps/current-work/#process-the-iframe-attributes It seems pretty explicit, I don't know how to make it more so. :-) I fixed it by making the navigation in that algorithm always an explicit self-navigation override. > Is it always the browsing context that contains the element, or > does it depend on which script is manipulating the src attribute (e.g., > via the DOM)? Always the iframe's nested browsing context. > Should setting the src attribute use an explicit self-navigation > override? Yes. > The easiest solution is probably to specify the source browsing context > explicitly, as we do for window.open > <http://www.whatwg.org/specs/web-apps/current-work/#dom-open> and > location.href > <http://www.whatwg.org/specs/web-apps/current-work/#dom-location-href>. It's already set explicitly, but it's set to its own nested browsing context, which is where the problem starts. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] seamless iframes
On Wed, 4 Apr 2012, Ojan Vafai wrote:
>
> 1. We should add iframe[seamless] { display:block; }.
> http://www.whatwg.org/specs/web-apps/current-work/#embedded-content-2
> already expects iframe:not([seamless]) { border: 2px inset; }. In 90%
> percent of uses, seamless iframes will not want a border and will want
> to fill their container. This way, seamless iframes behave roughly like
> sandboxable divs, which is what web developers want.
Done.
> 2.
> http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless
> "In visual media, in a CSS-supporting user agent: the user agent should
> set the intrinsic width of the iframe to the width that the element
> would have if it was a non-replaced block-level element with 'width:
> auto'."
>
> This doesn't get the behavior you'd want with cases that need
> shrink-wrapped behavior. Some cases that need handling:
>
>
>
>
Done.
On Wed, 4 Apr 2012, Ojan Vafai wrote:
>
> 3. The default margin on the body element inside a seamless iframe
> should be 0. Again, this is what 90%+ of uses will expect. We shouldn't
> require everyone using seamless iframes to have to set the body's margin
> to 0.
Done.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] multipart/form-data filename encoding: unicode and special characters
On Mon, 9 Jul 2012, Julian Reschke wrote: > > I agree with the methodology. However I would suggest to simply revise > RFC 2388. The precise details of the process of how it's done are up to whoever writes the spec text, they're not really relevant to this list. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] multipart/form-data filename encoding: unicode and special characters
On Thu, 3 May 2012, Evan Jones wrote: > On May 3, 2012, at 17:09 , Anne van Kesteren wrote: > > > > Yes. I think we should define multipart/form-data directly in HTML and > > thereby obsolete http://tools.ietf.org/html/rfc2388 as it is outdated > > and not maintained. > > Right; that would be ideal. Despite the fact that HTML5 references that > RFC, browsers don't really follow it. > > I would be interested in trying to help with this, but again I would > certainly need some guidance from people who know more about the > vagaries of how the various browsers encode their form parameters / > uploaded file names, and why things got that way. It probably would not > be helpful for me to try to draft an update to the spec without getting > the right implementers on board. If this is still something for which you have some time available, then the starting point for anything like this would be test cases, lots and lots of test cases. In this case, it would have to be something like a server that echoes the precise bytes sent by the client, for a huge variety of different setups: - various submission encodings - various form field names and types - various file submission filenames ...etc. I'd be happy to advise if this is something that still interests you. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Elements to markup article headings
On Sun, 22 Apr 2012, Andrés Sanhueza wrote:
>
> There are some analog conventions that does make sense to standardize in
> different markup languages. This is not necessarily the job of the HTML5
> team, but it may have those issues in mind. There are a few regarding
> the heading of newspaper articles, specific names differs, but meaning
> is the same:
>
> —The kicker / running head: a phrase that goes right before the
> heading, usually a short teaser or the name of a section.
> —The headline: the article title.
> —The drop deck / lead /lede: the paragraph that gives a short abstract
> of the article.
> —The byline: the line that contains meta info like the author, and/or
> the date of the article. This can go before the lead, after it or at
> the end of the article.
>
> There have been some discussion regarding each one which have been
> more or less clarified. The way to markup that with the current
> standard:
>
>
>
>
> Kicker
> Headline
>
> Deck
>
> Byline
> [...]
>
That seems fine. I would maybe go for:
Kicker
Headline
Byline with e-mail address
Lede rest of first paragraph
...
...but there's a variety of possibilities here.
> It looks fine, but I'm not entirely convinced by the tag for the byline,
> mainly because, even when it could be place differently or even multiple
> times inside a newspaper article, when it appears at the beginning it
> could make more sense to have it between the , but that is not
> possible due to the rule of not having tags with
> descendants and vice-versa.
The byline doesn't have to be in the ; as the spec says: "Bylines
and other information that could be suitable for both a header or a footer
can be placed in either (or neither). The primary purpose of these
elements is merely to help the author write self-explanatory markup that
is easy to maintain and style; they are not intended to impose specific
structures on authors."
> That does makes sense when sticking to what the names of the elements
> imply, yet conceptually I see no reason a as in "textual
> metadata of a section" can't be inside a ("lead of a section").
It's mostly for sanity's sake. People tend to consider their headers and
footers as separate peers, so we like to have the validator check that
they didn't accidentally end up nested.
HTH,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline Depth Does Not Correspond to Sectioning Depth?
On Mon, 26 Mar 2012, Hugh Guiney wrote: > > I am confused by the current definition of outline depth ( > http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#outline-depth), > > which, if I understand it correctly, states that the depth resets with > each sub-outline. > > So, in the following: > > > Document Title > > Section Title > > Subsection Title > > > > > �each heading would have an outline depth of 1, yet for: > > > Document Title > Section Title > Subsection Title > > > �which is, according to the spec, semantically identical to the previous > example, each heading would instead have an outline depth of 1, 2, and 3 > respectively. > > At least, that is how this implementation ( > https://github.com/hoyois/html5outliner) behaves; I raised this issue > with the implementor and he seems to think it is the correct behavior�if > so, why? Wouldn't it make more sense to have the depths be 1, 2, and 3, > whether explicit sections are used or not? The spec was indeed confusing here. I've clarified the definition of "outline depth" to make it say that it is the depth in the _outermost_ outline that matters (since the element above is really in three outlines -- that of the , and that of each -- but the depth that matters is just that of the ). HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg]
On Wed, 7 Mar 2012, Roland Steiner wrote: > > In this regard, I would also like to try to re-ignote the discussion on > the fate of @-rules within
Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Thu, 5 Jul 2012, Charles Pritchard wrote: > On Jul 5, 2012, at 10:06 PM, Ian Hickson wrote: > >> > >> I think its up to the author to manage their set of paths > >> appropriately, independently from the drawing operations. > > > > Having the drawing mechanism work in a tightly integrated fashion with > > the region code IMHO helps authors avoid bugs. You don't have to track > > which regions you've defined, you just make sure to draw the regions > > while you're drawing the paths and it all Just Works. Not having to > > track the regions is the entire point of how this API was designed -- > > it's also the main differentiating factor between this API's design > > and the design of hit testing in retained-mode APIs such as SVG. > > It's a poor design you've settled on: the purpose of these methods is to > associate path information with DOM nodes. Oh, no, not at all. That's at best a minor use case compared to the main bulk of the use cases for this feature. I encourage you to read the e-mail that introduced these features a few weeks ago, where I go into much more detail about the design. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Thu, 5 Jul 2012, Simon Fraser wrote: > On Jul 5, 2012, at 2:25 PM, Ian Hickson wrote: > > On Thu, 5 Jul 2012, Edward O'Connor wrote: > >> > >> As things currently stand in the spec, implementations basically need > >> to keep N+1 bitmaps per canvas, where N is the number of hit regions. > >> I doubt any implementors would be enthusiastic to implement hit > >> regions like this. From a WebKit perspective, we'd much prefer > >> keeping a Path for each hit region, and then simply using > >> isPointInPath for hit testing. This also implies that the current > >> piggybacking of "Clear regions that cover the pixels" in clearRect() > >> could go away. Yay! :) > > > > You only need one bitmap to implement the hit testing. > > > > (Or you can do it using paths, sure. The effect is the same, but it's > > probably quicker to use a bitmap.) > > I don't think the spec should be written with a particular > implementation in mind, nor should it dictate one. I agree it shouldn't (and doesn't) dictate one. But it's crazy to not consider implementations at all when writing a spec. That way lies madness like requiring O(N^2) algorithms and solving the halting problem and all kinds of other disasters (all of which I've seen in real proposals). > I also strongly object to having to update this hit testing bitmap > and/or path set on drawing operations like clearRect(). That will > potentially hurt performance. How so? If it's a path set, you just add a rectangle (you can keep the list of shapes down by occasionally running pruning algorithms to remove shapes entirely contained by later ones). If it's a bitmap, it's even easier; you just wipe the rectangle in the bitmap. > I think its up to the author to manage their set of paths appropriately, > independently from the drawing operations. Having the drawing mechanism work in a tightly integrated fashion with the region code IMHO helps authors avoid bugs. You don't have to track which regions you've defined, you just make sure to draw the regions while you're drawing the paths and it all Just Works. Not having to track the regions is the entire point of how this API was designed -- it's also the main differentiating factor between this API's design and the design of hit testing in retained-mode APIs such as SVG. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions
On Thu, 5 Jul 2012, Edward O'Connor wrote: > > As things currently stand in the spec, implementations basically need to > keep N+1 bitmaps per canvas, where N is the number of hit regions. I > doubt any implementors would be enthusiastic to implement hit regions > like this. From a WebKit perspective, we'd much prefer keeping a Path > for each hit region, and then simply using isPointInPath for hit > testing. This also implies that the current piggybacking of "Clear > regions that cover the pixels" in clearRect() could go away. Yay! :) You only need one bitmap to implement the hit testing. (Or you can do it using paths, sure. The effect is the same, but it's probably quicker to use a bitmap.) -- 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 Fri, 29 Jun 2012, Boris Zbarsky wrote: > On 6/29/12 6:19 PM, Boris Zbarsky wrote: > > In any case, I believe the spec is wrong in one aspect: in the case > > that there is a default button, what needs to happen is a click event > > on that button, not just a triggering of its activation behavior. In > > particular, onclick handlers need to fire and the activation behavior > > should only happen if preventDefault is not called on the event. > > Note that depending on how defines handling of click > events, we may get the right thing happening with it for free. > Unfortunately, I'm failing to find where the spec talks about the actual > behavior of @disabled on submit controls. :( It's a bit of a tortuous route. The definition of says: # The disabled attribute is used to make the control non-interactive and # to prevent its value from being submitted. - http://www.whatwg.org/specs/web-apps/current-work/#the-input-element ...which links to: # A form control is disabled if its disabled attribute is set [...] - http://www.whatwg.org/specs/web-apps/current-work/#attr-fe-disabled This is used in the element section: # When an input element is disabled, it is immutable. - http://www.whatwg.org/specs/web-apps/current-work/#concept-input-immutable This is then used in the type=submit definition: # If the element is immutable, it has no activation behavior. - http://www.whatwg.org/specs/web-apps/current-work/#submit-button-state-(type=submit) And now the implicit submission section says: # If the platform supports letting the user submit a form implicitly (for # example, on some platforms hitting the "enter" key while a text field is # focused implicitly submits the form), then doing so for a form whose # default button has a defined activation behavior must cause the user # agent to run synthetic click activation steps on that default button. # # Consequently, if the default button is disabled, the form is not # submitted when such an implicit submission mechanism is used. (A button # has no activation behavior when disabled.) - http://www.whatwg.org/specs/web-apps/current-work/#implicit-submission HTH, -- 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 Fri, 29 Jun 2012, Boris Zbarsky wrote: > On 6/29/12 5:24 PM, Ian Hickson wrote: > > Let me know if it's not quite right. I wasn't sure exactly what weird > > things to test. I mostly relied on WebKit's (specifically Chrome's) > > behaviour here since they were apparently the ones most recently > > affected by real compat reasons to implement something here so maybe > > they are the closest to what the Web today actually needs (?). > > What were the differences between Chrome and Gecko here, if you recall? > I'm somewhat interested. The main difference was that Chrome and Firefox differ in what input types they support, which affects which they allow to affect the implicit submission thing. > In any case, I believe the spec is wrong in one aspect: in the case that > there is a default button, what needs to happen is a click event on that > button, not just a triggering of its activation behavior. In > particular, onclick handlers need to fire and the activation behavior > should only happen if preventDefault is not called on the event. For > example, this testcase: > > > http://w3.org";> > > > > > should alert and not submit. Yes, I know this is totally screwy. :( Oh, wow, yeah, the spec was just bogus there, sorry about that. I never got around to updating it to handle the activation behaviour stuff properly after fixing that a few years back. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Security Issue- Iframe Sandbox attribute - Clarity of operation
On Tue, 6 Mar 2012, Sethu mathavan wrote: > > My code for iframe is . Expected > working is that scripts in the "xyz.htm" should not be executed. > Normally,it works fine. > > But i was able to alter the sandbox attribute by intercepting and > modifying the the response with a proxy tool as follows: src="xyz.htm" sandbox="allow-same-origin allow-scripts"> Now, browser > allows the script in xyz.htm to get executed and original functionality > is altered. > > The main purpose of implementing the sandbox attribute is to restrict > the contents within the particular frame. But that very purpose is being > compromised. This facilitates the Man-in-the-middle attack. Is this the > intended working of the attribute or is there any modifications planned > for the future? Need more clarification on this. On Tue, 6 Mar 2012, Adam Barth wrote: > > The feature is working as intended. If you can intercept and modify the > enclosing page, why not just insert a script block and XSS it directly? I agree with Adam here. > By the way, you might also be interested in the sandbox CSP directive, > which lets you apply a sandbox policy to a resource regardless of the > context in which it's used: > > http://www.w3.org/TR/CSP/#sandbox Even with this, if you can do a man-in-the-middle attack, it provides with minimal to no protection. If you are concerned with MITM attacks, TLS is the right solution. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] media attribute behavior, static or dynamic ?
On Fri, 11 May 2012, Simon Pieters wrote: > > I'm still a bit skeptical about the utility of . Maybe it > should be dropped from the spec. > > It is not appropriate for choosing between low resolution and high > resolution, because the environment can change (e.g. the user might > fullscreen the video after it has begun loading, and want high > resolution). Also, bandwidth is not available in MQ, but even if it was, > the user agent is in a better position to determine what is appropriate > than the author. > > It would be better to have a solution where the user agent is informed > about which streams are available and what properties they have, and let > the user and user agent switch streams at will. Maybe this should happen > on the network layer, keeping the same selected URL. I don't disagree. I think the right solution is to move all of this into the network layer, personally. I haven't changed the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] media attribute of element, default behavior on getting the property.
On Tue, 8 May 2012, Paul Adenot wrote:
>
> Currently implementing the "media" attribute for the element in
> Gecko, we are not sure on how to interpret the spec when the attribute
> is not set in the HTML source.
>
> Considering this snipped of code :
>
>
>
>
>
> What should document.getElementById("asource").media [1] be ?
>
> The spec [2] currently says :
>
> > The default, if the media attribute is omitted, is "all", meaning that
> > by default the media resource is suitable for all media.
>
> At that point, we understand that if no media attribute is specified,
> the expression [1] should return "all".
No, that sentence doesn't say anything except that "the default" (a
constant value used elsewhere in the spec) is the value "all".
Specifically, this part of the sentence is a definition:
# The default, if the media attribute is omitted, is "all"
...and this part of the sentence is a non-normative statement of fact:
# meaning that by default the media resource is suitable for all media.
The constant part is never used in the specification, so it actually has
no effect on implementations whatsoever. It is, effectively, also a
statement of fact. (It it describing what happens in step 6 of the second
set of steps of step 7 of the " resource selection algorithm", which says:
"If candidate has a media attribute whose value does not match the
environment [...]", where the absence of the media attribute thus causes
the step to be ignored -- meaning it behaves as if it was "all".)
I've tried to make this clearer.
> Then spec then says :
>
> > The IDL attributes src, type, and media must reflect the respective ?
> > content attributes of the same name.
>
> At this point, we understand that [1] should return an empty string, but the
> is matched as if media was "all".
>
> The part of the spec about reflection [3] states :
>
> > If a reflecting IDL attribute is a DOMString attribute but doesn't
> > fall into any of the above categories, then the getting and setting
> > must be done in a transparent, case-preserving manner.
>
> which means that [1] should return an empty string.
Correct.
--
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 Tue, 21 Feb 2012, Boris Zbarsky wrote: > On 2/21/12 10:47 PM, Dimitri Glazkov wrote: > > I made WebKit match this behavior a couple of years ago: > > https://bugs.webkit.org/show_bug.cgi?id=9756 > > Ah, interesting. Some of the links in that bug indicate that people are > in fact depending on this behavior I've tried to define this in the spec. It's a bit esoteric, but... Let me know if it's not quite right. I wasn't sure exactly what weird things to test. I mostly relied on WebKit's (specifically Chrome's) behaviour here since they were apparently the ones most recently affected by real compat reasons to implement something here so maybe they are the closest to what the Web today actually needs (?). On Tue, 3 Apr 2012, Boris Zbarsky wrote: > On 4/3/12 5:14 PM, Glenn Maynard wrote: > > Ten years later it's still giving me headaches, when I try to do a > > trivial two-input login form without a browser submit button, and find > > that every obvious way of hiding the submit button breaks implicit > > submit in one browser or another. Do I really need to stick the > > submit button in an overflow: hidden, 0x0 div? I know I found a less > > ugly workaround for this the last time I hit this... > > Well, the fact that display:none makes it not submit is clearly a > browser bug in the browsers it happens in. Indeed. On Tue, 21 Feb 2012, Glenn Maynard wrote: > > I don't think the existence of implicit submit should depend on platform > conventions, though, for interop on forms without visible submit > buttons. The form implicit submit takes is a platform convention, but it > should be required to exist in some form or another. User agents aren't actually required to let users input anything, so it doesn't make much sense to require submission be possible... On Thu, 24 May 2012, Rob Crowther wrote: > On 22/02/12 00:35, Ian Hickson wrote: > > I've changed the spec to be clearer that CSS cannot be taken into > > account when determining the default. The default button is just > > always the first submit button in the form. > > What about the situation where there isn't a button? Implicit > submission still seems to happen on forms which have just a single > element, for example: > > http://www.boogdesign.com/examples/forms2/test-validate-1.html > http://www.boogdesign.com/examples/forms2/test-validate-2.html > > These both trigger the form validation algorithm in Firefox, Opera & > Chrome if you just hit return. This form with two inputs doesn't > trigger implicit submission: > > http://www.boogdesign.com/examples/forms2/test-validate-3.html > > But add a submit button and it does: > > http://www.boogdesign.com/examples/forms2/test-validate-4.html > > Because in 4.10.22.2 everything hinges on the 'default button' this > behaviour doesn't seem to be covered. Is this intentional? I've updated the spec to hopefully better match this, as noted above. Cheers, -- 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, 15 Feb 2012, Tab Atkins Jr. wrote: > On Wed, Feb 15, 2012 at 11:26 AM, Ian Hickson wrote: > > 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? > > As far as I know, we (google) would prefer to do nothing with > window.find(), so we can use it for the Selectors API. No opinion on > whether the functionality is useful under another name. On Wed, 15 Feb 2012, Rick Waldron wrote: > > +1 to TJ's mention of find for use in the Selector API: > > http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0277.html On Thu, 16 Feb 2012, Tim Down wrote: > > For what it's worth as author of a small library currently working on > implementing something like this feature, I have no love for > window.find(), even if it were consistently implemented in browsers. I > would prefer the use case I described to be met by a different API, > which would ideally provide node-independent text-based > creation/mutation of Ranges, with features similar to those provided by > Microsoft's TextRange. Given the lack of interest in the feature, I have removed it from the spec and recommend to implementors that they drop support for the API. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Character-encoding-related threads
On Tue, 14 Feb 2012, Simon Pieters wrote: > On Mon, 13 Feb 2012 18:22:13 +0100, Ian Hickson wrote: > > > I think this is like saying that requiring 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, "" is the best we could do. > > It is a burden, but it's not significantly difficult or anything. I consider all "boilerplate" to be a significant burden. I think there's a huge win to making it trivial to create a Web page. Anything we require makes it less trivial. Currently you need a DOCTYPE, a character encoding declaration, a title, and some content. I'd love to be in a position where the empty string would be a valid document, personally. > > 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. > > The list may well be longer, I haven't checked, but I don't think that > matters. The resolving URL problem is a bad problem because it means > links will stop working for users that have a different default > encoding, so those users leave and go to a competitor site. The form > problem is a bad problem because it means that the database will be > filled with content using various different encodings with no knowledge > of what is what, so when the author realizes this and "fixes" it by > declaring the encoding, it's already too late, the data is broken and is > very hard to repair. > > Letting authors get themselves in a situation where they have broken > data even though it could have been easily prevented seems more like an > undue burden to me. > > Note that both of these features can be hidden in scripts where > validators currently don't even look, so I think it's not a good idea to > make the requirement conditional on these features. Fair enough. -- 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 Thu, 16 Feb 2012, Justin Lebar wrote:
> On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson wrote:
> > On Wed, 15 Feb 2012, Justin Lebar wrote:
> >> > - 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.
>
> When I implemented pushState, I explicitly didn't want authors to have
> to rewrite all their anchor links after they changed the document's
> current URI.
>
> From an author's point of view, there's no such thing as the document's
> original URI and, unless you're a nerd, you've never heard of the base
> URI. There's just the document's URI, modified by pushState.
>
> From this point of view, I'd say it's less surprising that relative URIs
> would break when you change directories (hey, you *asked* for it) than
> that anchor refs would update the browser's address bar and
> document.location relative to the old URI.
>
> If we did make the change you're suggesting, we'd have to check that it
> doesn't break at least the major sites which use pushstate (Facebook,
> anyone?). And I'd want to try to coordinate the change with WebKit so
> we quickly move away from the old behavior. But I'm not convinced it's
> worthwhile, given that there's at least an argument for the current
> behavior.
On Mon, 20 Feb 2012, Sean Hogan wrote:
>
> An obvious use-case for pushState() is facilitating an enhanced
> user-experience for page navigation within a site. In this case the process of
> document updates + pushState({},null, "foo/bar.html") should result in the
> same DOM as if foo/bar.html was browsed to directly.
>
> For example, imagine a site that has some pages amenable to this usage:
>
> /page1.html
> /page2.html
> /subdir/page3.html
>
> These contain some page specific content wrapped in some generic page
> template.
> (I'm assuming that pages amenable to document updates + pushState() have a lot
> in common, otherwise why use pushState().)
>
>
>
>
>
>
> I hope you are not distracted by my enormous banner. You may want to href="#content">skip directly to the main content of this page.
>
>
> My Site
>
>
>
> Page 1
> Page 2
> Page 3
>
>
>
>
>
>
>
>
> The following stylesheets and images are used:
> /style.css
> /logo.png
>
>
> If page creation was all performed on the server using this template then...
> - /page1.html & /page2.html would be okay
> - /subdir/page3.html would be broken:
> 1. has a relative path and refs the non-existant
> /subdir/logo.png
> 2. Similarly, with #nav all have rel paths to nowhere
> 3. Note that the top skip link is OK in all pages
>
> If a pushState() facilitated mechanism was used for navigation
> (a naive implementation which just inserts page-specific content inside id="content">)
> and navigation started at /page1.html, thence to /page2.html and
> /subdir/page3.html,
> the images and hyperlinks in /subdir/page3.html would be fine...
> except for the top skip link which references the #content anchor.
>
> Obviously this page template needs fixing and for this example, simply
> changing rel paths to absolute will be sufficient for both the server
> generated and browser updated documents. Except that pushState()
> assisted navigation would break the top skip link (assuming the current
> SPECIFIED behavior).
>
> For all the issues in this example I think Justin's proposal is
> preferable to what is currently specified.
Fair enough. I have changed the spec accordingly.
> By the way, this doesn't quite match what is currently implemented in
> Firefox and Webkit. According to my testing, although the baseURI after
> pushState() is the same as the documentURI (so far I've tested ,
> and elts) the actual images and stylesheets used for
> rendering
[whatwg] Drag and drop feedback
that trust each other but
cannot access each other?
> Our proposal takes its cues and algorithms from the postMessage API, and
> allows the source site to restrict drop targets to only those origins
> which it trusts, and allows drop targets to see which origin was the
> source of a drag. The majority of the algorithm can be copied from
> postMessage, including the syntax for allowed target origins.
The postMessage() security mechanism is generally considered to have been
poorly designed, so I don't think that's a good plan.
See, e.g.: http://seclab.stanford.edu/websec/frames/post-message.pdf
However, it's not clear to me that there is really a problem to solve
here, so I haven't examined the proposal in detail to see if it suffers
from the same problems. I think a deeper discussion of the use cases is
required first.
In general, though, I would expect us to address the general area using
promises and message ports, leveraging much of the existing infrastructure
rather than introducing yet another security mechanism.
On Fri, 17 Feb 2012, Anne van Kesteren wrote:
>
> * Firefox chooses to reinitialise dropEffect in dragend to have the same
> value it had at the start of drop. Opera and Chrome choose to be
> consistent, and accept the last value it had - this is unspecified per
> spec
As far as I can tell, this is specified precisely. In 'dragend' you use
the current drag operation value.
> =Dragging inputs and interactive elements=
>
> * We have decided to make certain interactive elements be "special", for
> compatibility with other browsers, and user expectations. This is not covered
> by the spec. A page is highly unlikely to make an editable element be
> draggable but it's quite possible to have an input somewhere inside a
> draggable element. The user still wants to be able to select text in that
> element and interact normally with it.
> * Input/select/textarea/button cannot be dragged.
> * ContentEditable elements cannot be dragged.
> * Editable SVG elements cannot be dragged.
> * Scrollbars must respond as scrollbars, not draggable points.
Why would you explicitly ignore "draggable" on an element that has it? If
the author didn't want it draggable, he presumably wouldn't set it that way.
> [lots of other bugs in browsers]
Please do file bugs on these!
On Thu, 23 Feb 2012, Daniel Cheng wrote:
>
> For a long time, WebKit returned types as an Array rather than a
> DOMStringList. I fixed this recently, but arv pointed out that
> DOMStringList is deprecated in favor of Array:
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#interface-domstringlist
>
> Given that, wouldn't it make sense to change event.dataTransfer.types to be
> a live Array instead of a live DOMStringList? It's not needed for legacy
> compatibility with IE, which didn't have .types. It was implemented
> differently in Gecko and WebKit, so pages ought to be checking for this
> already with:
> if (event.dataTransfer.contains) {
> ...
> } else if (event.dataTransfer.indexOf) {
> ...
> }
> As a result, the burden of such a change to well-behaved web developers
> should be minimal.
Done.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Reconcile document.URL and document.documentURI?
On Thu, 2 Feb 2012, Anne van Kesteren wrote: > On Fri, 13 Jan 2012 23:30:06 +0100, Ian Hickson wrote: > > > I moved document.URL to DOM Core, made document.documentURI > > > readonly, and have them both return the same URL concept, which > > > defaults to "about:blank". > > > > They now always return about:blank, since this URL concept is never > > set. > > > > So um... when should it be set? Is it just "the document's address" > > but with the change that the document's address is about:blank for > > create*Document()-created documents? > > Yes, the HTML standard is already correct, except it no longer needs to > define document.URL and it should probably say it updates the > concept-document-url concept from DOM rather than introducing its own > new concept (you still need to introduce the "current" one though). Done (though I just said "document's address" was what DOM Core called a "URL", rather than calling it "URL", since I use the term "URL" for something else already -- namely, the data type). -- 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 Wed, 28 Mar 2012, Charles Pritchard wrote: > On 3/28/2012 2:41 PM, Ian Hickson wrote: > > > Currently, authors can create a large canvas, and place it in a div: > > > > > > > > This can is larger than the div > > > > > ... > > > The idea here is to enable scroll with limited height/width canvas layer > > > to work well. > > > > > I don't really understand the use case here. Could you elaborate? > > > Canvas authors often minimize the amount of memory they use in applications by > limiting the number of layers and the width and height of the Canvas. > > The following code is meant to explain, it is not valid code. > > Where in HTML, we may have a div with scroll overflow: > My presentation of things > > In Canvas we will often use a canvas with virtual overflow [synthetic scroll > bars]: > then synthetic scroll bars > and we repaint the canvas. > It's quite a bit easier to simply use native scroll bars, but native scroll > bars have many quirks across vendors. > > The easier route is usually to use a div with native scrolling and a larger > canvas: > style="width: 300%; height: 100%"> > > For some cases, it would be nice to have synthetic overflow better integrated > with the browser and apis: > > > Setting scrollLeft or scrollTop would trigger onscroll() as it does for other > overflow elements. > The semantic is available. Just have the canvas positioned to not scroll in the div, and the div sized to be whatever size the original content is, and repaint the canvas when the user scrolls the div. Or, implement custom scrollbars or other scroll mechanisms in the canvas itself, if that's really necessary. Admittedly, I haven't tried either of these techniques myself, but they don't a priori seem that difficult to set up. I don't think we should be adding new features just to make this easier, at least not without more compelling evidence that it is a hard problem to address. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] and Content-Security-Policy
On Fri, 22 Jun 2012, Adam Barth wrote: > >> > >> When creating a srcdoc document, in the same way that we copy the > >> parent document's origin onto the child document, we should: > >> > >> 1) /enforce/, on the srcdoc document, all CSP policies currently being > >> enforced on the parent document. > >> 2) /monitor/, on the srcdoc document, all CSP policies currently being > >> monitored on the parent document. > > > > [...] why is srcdoc="" special here? > > It's special because it's a way of specifying a resource other than > providing a URI for that resource. If you like, we could consider this > an "inline" resource and block it unless the policy contains > 'unsafe-inline', but that seems less useful that just inheriting the CSP > policy the same way we inherit the parent document's origin and title. Fair enough. I think this belongs in the CSP spec, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] and Content-Security-Policy
On Mon, 7 May 2012, Adam Barth wrote: > > == Summary == > > When creating a srcdoc document, we need to be careful to avoid > introducing a Content-Security-Policy loophole. > > == Details == > > Consider a document with the following Content-Security-Policy: > > Content-Security-Policy: default-src 'none'; frame-src * > > Now, imagine the following injection vulnerability in index.php: > > Hello > > This Content-Security-Policy is supposed to prevent the attacker from > being able to inject script into index.php. However, consider the > following value for $username: > > $username = ' srcdoc="alert(parent.document.cookie);">'; > > In this case, we could get in trouble if the user agent doesn't > enforce the parent document's Content-Security-Policy on the srcdoc > document because the user agent copies the parent document's origin > unto the child document. > > == Proposal == > > When creating a srcdoc document, in the same way that we copy the > parent document's origin onto the child document, we should: > > 1) /enforce/, on the srcdoc document, all CSP policies currently being > enforced on the parent document. > 2) /monitor/, on the srcdoc document, all CSP policies currently being > monitored on the parent document. > > Please see > <http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html> > for definitions of these terms. How is this different from the same attack but with: $username = '';> ..., or: $username = '';> ...? That is, why is srcdoc="" special here? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] allow-popups in iframe sandbox
On Sun, 29 Jan 2012, Charles Pritchard wrote: > > The allow-popups proposal for iframe seems to be ready for prime time. > The Webkit patch was resolved, MS implemented it in their latest > previews. This is specced now. On Mon, 30 Jan 2012, Ian Melven wrote: > > Just to make sure I understand the proposal correctly : if allow-popups > is specified and a new browsing context is being created, this inherits > the sandbox flags of the document creating the new popup/browsing > context ? Yes. > This does seem to complicate the algorithm to determine if a navigation > is allowed quite a bit. Yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] The so-called 'magic iframe' feature
On Thu, 26 Jan 2012, Andrew Oakley wrote: > > > > outside a document doesn't initiate a load, so it's case is > > different. > > I'm not sure it is - we can create an in the document then > remove it before it loads. Most browsers seem to give up on loading the > contents of the iframe if you do this (IE continues to delay the load > event until it has loaded the iframe). > > As far as I can tell HTML5 says that you shouldn't do anything when an > iframe is removed from a document (and therefore the frame should > continue to load and delay the load event, assuming it isn't GC'd). > > I think we should be consistent here - if we continue to delay the load > events for , and after they have been removed from > the tree then the same should be true for . On Thu, 12 Apr 2012, Ojan Vafai wrote: > > We should add a keepalive attribute to iframes that prevents iframes > from being unloaded/reloaded when removed from or appended to a > document. Similarly, a disconnected iframe with keepalive should load. > If the keepalive attribute is removed from a disconnected iframe, then > it should unload. > > I'm not terribly happy with the name 'keepalive', but I can't think of > anything better at the moment. > > As iframes increasingly become the standard way of achieving certain > tasks (e.g. sandboxing), it's increasingly important to be able to move > them around in the DOM. Right now, to achieve this sort of keepalive > behavior, you have to keep the iframe always appended to the document > and position it absolutely as the document changes. On Thu, 12 Apr 2012, Adam Barth wrote: > > We just got finished removing this feature from WebKit because it caused > many security and stability problems. It turns out that there's a lot > of code in browsers that can't cope with a disconnected iframe being > alive. I've changed the spec to make removing an iframe from a document cause the nested browsing context to be discarded. (This includes when a node is moved from one place in the DOM to another.) On Mon, 16 Apr 2012, Darin Fisher wrote: > > Can you hide this behind adoptNode just as we did for "magic iframe"? > The nice thing about adoptNode is that the browser gets told both the > source and destination parent nodes. This way there is never a > disconnected state. > > So long as we unload when moving between documents, we should be pretty > safe as far as the issues which plagued magic iframe are concerned. On Mon, 16 Apr 2012, Erik Arvidsson wrote: > > FWIW, IE used to not reload iframes when they were moved around in the > tree. They changed this behavior in IE9 so maybe there was some compat > issues? I couldn't find a browser that let iframes survive even being moved around the same document. (I was unable to test Opera or IE, though.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] toDataURL() for image/video?
On Tue, 29 May 2012, Ashley Gullen wrote: > > Has toDataURL() (from canvas) been considered for ordinary image and > video elements? Seems like it would be useful for pure javascript > applications. Currently it can be done by creating a new canvas, getting > a 2D context, drawImage(), then canvas.toDataURL(). However adding it > to images directly would be a useful convenience method, avoid the > performance overhead of a new canvas, and probably be straightforward to > define/implement. > > Use cases for myimage.toDataURL(): > - deep copy an image (imga.src = imgb.toDataURL()) Why can't you do imga.src = imgb.src? > - send an image in JSON data Why can't you just send the URL? If you really can't, then you can still just fetch the image data using XHR, and then send the blob directly, which seems more efficient than requiring the UA to decode the image then reencode it as a PNG. > - conveniently store in webstorage/other permanent storage (possibly > also for caching purposes?) You can store blobs into IndexDB directly. > - downloading an image to disk (depending on other features like > anchor's download attribute) Browsers offer this feature already. > These are especially useful with javascript-synthesised images. I > suppose it would have to be disallowed for cross-domain images, else > canvas' dirty flag can be worked around by deep copying a cross-domain > image. If it's a JS-synthesised image, just synthesise it straight to canvas and use that instead. > It seems to make sense to also consider it for video, but it may be > difficult to deal with streaming or strings storing very large amounts > of data. How about a snapshot() method that returns a new Image() with > the contents of the currently displaying frame? This can also be worked > around by drawImage() to a temporary canvas, so exists just as a > convenience method as well. I think if we want to support doing things to frames of videos, we should approach the problem in much the same way as we do for audio, with a dedicated off-the-main-thread processing pipeline. > Use cases: > - easily get a representative frame, e.g. for a thumbnail > - easily snapshot the current frame when displaying webcam feed with > getUserMedia(). e.g. var myPhoto = video.snapshot();, or some of the above > uses with video.snapshot().toDataURL(). On Tue, 29 May 2012, Glenn Maynard wrote: > > It doesn't need any overhead, actually. You can create a single canvas > for all of your readback operations. As long as you keep the canvas out > of the document, it doesn't even need to actually blit the image; a > smart implementation can delay that, so when you read the data back it > can get the pixel data directly from the original image. This is more > important with toBlob, where implementations might be able to skip the > compression step and just return the original compressed data. > > (These are use cases for reading back images--they're not really use > cases for adding another way to do it.) Indeed. It's not clear that adding this new feature has a compelling need. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Firing canplaythrough when caches/buffers are full
On Mon, 28 May 2012, Robert O'Callahan wrote: > > We encountered an app that uses "canplaythrough" on a video element to > trigger execution of the app "so we don't start playing the video until > we can do so without stuttering". http://gaiamobile.org/apps/cubevid/ > This approach works fine on desktop browsers. On mobile browsers, we > want a smaller limit on the amount of data buffered by the media > subsystem. That means we pause the download before "canplaythrough" > would fire, so it never fires, so the app doesn't work. > > We could fix this particular app, but this seems like a natural thing > for authors to do and get wrong. > > I propose fixing this by having the UA enter the HAVE_ENOUGH_DATA > readyState when the UA decides to suspend a download indefinitely and > the preload state is "Automatic" (or overriden by "autoplay" being set). > > We have checked in a patch to Gecko to do this. (Note that for a long > time, Gecko has triggered playback of autoplay elements when suspending > due to media buffers being full. The new change makes us enter > HAVE_ENOUGH_DATA as well.) I've adjusted the definition of HAVE_ENOUGH_DATA to include this case. You have to have at least the conditions of HAVE_FUTURE_DATA (i.e. you have to be able to move at least one frame if play() is called), but beyond that, if you are in a state where waiting longer isn't going to help, you can just jump to HAVE_ENOUGH_DATA and fire the event. (The goal of the state and event is for apps to know how long to wait, so obviously if waiting longer isn't going to be helpful then it makes no sense to not fire the event.) On Wed, 30 May 2012, Jer Noble wrote: > > For what it's worth, the Mac port of WebKit has this exact behavior: > <http://trac.webkit.org/changeset/97944>. It would be good to formalize > this, however. On Wed, 30 May 2012, Andrew Scherkus wrote: > > Chrome's canplaythrough logic (which admittedly needs a little work) has > similar behaviour. I agree it'd be good to formalize the behaviour. > > Rob: when you say to suspend a download indefinitely would this coincide > with dropping the networkState to NETWORK_IDLE and subsequently firing a > suspend event? On Thu, 31 May 2012, Robert O'Callahan wrote: > > I'm not sure whether we want to require that the readyState go to > HAVE_ENOUGH_DATA every time networkState goes to NETWORK_IDLE, though. I have indeed not required that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The set of supported @type values for
On Fri, 25 May 2012, Boris Zbarsky wrote: > > The list is at > http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#support-the-scripting-language > > or > http://dev.w3.org/html5/spec/the-script-element.html#scriptingLanguages > depending on which you prefer to read. > > It seems to include several values that no UA actually supports, > apparently because of the way the spec uses the same list to deal with > both @language and @type. See compat testing data at > https://bugzilla.mozilla.org/show_bug.cgi?id=672814#c6 and the testcase > I used to generated that data at > https://bug672814.bugzilla.mozilla.org/attachment.cgi?id=627261 > > At the moment our plan in Gecko is to just implement this list as-is, I > think: it's a superset of what everyone implements, and it just doesn't > feel worth pushing back on the two Presto-only items and the three "no > one implements this" items. > > This mail is just a heads-up for people in case they want to protest, > before we go ahead and ship this full list in Gecko. On Fri, 25 May 2012, Ojan Vafai wrote: > > Meh. Seems fine to me. My mild preference would be to at least remove > the three that no one implements, but I share you're feeling that it's > not worth arguing over either way. Filed an equivalent WebKit bug: > https://bugs.webkit.org/show_bug.cgi?id=87527. On Fri, 25 May 2012, Maciej Stachowiak wrote: > > If the weird values are just for compatibility, then I think it would be > better to change the spec to drop the ones no one implements. I > certainly would not want the list of versioned types to expand over time > with new JavaScript versions, so there is no need for it to be a > consistent or logical set. On Sat, 26 May 2012, Anne van Kesteren wrote: > > That is done to define language and type using the same underlying list > of values. We can of course change the way language ought to be > implemented. As Anne points out, the weirdness here is just because the spec tries to simplify how "language" and "type" are implemented by making them use the same logic (basically, though check the spec for the details, the logic now is that we use type='' if we have it, else the value of language='' with text/ prepended). Since the union of what was needed to support that had such a great overlap with what was actually implemented, it didn't seem worth it to instead have two almost identical lists. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] runat (or "server") attribute
On Sun, 13 May 2012, Benjamin Hawkes-Lewis wrote: > On Sun, May 13, 2012 at 1:47 AM, Brett Zamir wrote: > > With Server-Side JavaScript taking off, could we reserve "runat" (or > > maybe an even simpler and more concise "server" boolean attribute) for > > a standard and (via CommonJS) potentially portable way for server-side > > files to be created (and discourage use of HTML-unfriendly and > > syntax-highlighter-unaware processing instructions)? > > "server-side files to be created" - what do you mean? > > What would this attribute do? On Sun, 13 May 2012, Brett Zamir wrote: > > So, no matter the Server-side JavaScript engine, one could write code > like tihs: > > You loaded this page on
Re: [whatwg] implementation feedback
On Fri, 15 Jun 2012, Simon Pieters wrote: > On Thu, 14 Jun 2012 20:32:16 +0200, Ian Hickson wrote: > > On Thu, 14 Jun 2012, Simon Pieters wrote: > > > > > > It's not more. But it still is. Even though images aren't required > > > to load at all, you still recently changed the way they load to be > > > compatible (http://html5.org/r/7128 ). We should also specify how > > > videos load to be compatible. We can do it now and get everyone to > > > align on a good behavior, or we can wait and do it in a few years > > > when Web content relies on what the market leader does, whether > > > that's good or bad behavior. > > > > I don't understand what behaviour it is that you think we should > > define. > > When preload=none, step 2 of > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-resource > > should not be optional. > > The effective (internal) preload state should be defined. > > It should also be defined that with preload=metadata, readyState should > never go beyond HAVE_CURRENT_DATA, even for a data: URL or otherwise > fully cached resource. Making it non-conforming for a user agent to aggressively cache resources, especially if the user has asked for it, is a non-starter. There are going to be cases where that's what the user wants, and I don't see why we would have to make this non-conforming. > > As far as I can tell, the spec is as detailed as it can be here given > > the range of possible implementation strategies that we need to allow. > > > > Could you give a concrete example of what you are concerned about? > > Then we should stop firing "suspend" in the preload=none case, or fire it in every case if preload=non, even if the UA immediately unsuspends. But I'm not convinced anyone is going to hook into onsuspend in this way. There'd be no point as far as I can tell, and it's more complicated than the alternative (just run the code straight away without waiting). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Cross-document messaging] Restrictions on targetOrigin
On Fri, 10 Feb 2012, João Eiras wrote: > > Step 1 of the spec [1] for postMessage says: > > "1. If the value of the targetOrigin argument is neither a single U+002A > ASTERISK character (*), a single U+002F SOLIDUS character (/), nor an > absolute URL, then throw a SyntaxError exception and abort the overall > set of steps." > > The absolute URL part will create problems when the origin of the > scripting environment does not serialize to an absolute URL. > > For instance, if you have two documents A and B in a non http context, > where typically the origin will be "null", like file: or data:, and post > a message from A to B, B will receive a message event which event.origin > property has a value of "null". If the listener then does > > # event.source.postMessage(reply, event.origin) > > (which is a code snippet easily found in online tutorials) step 1 causes > that call to fail with a SYNTAX_ERR exception. > > Step 1 should be changed to instead of referring to an absolute URI, > refer to a valid origin, as serialized by the origin serialization > algorithm. If the origin doesn't serialise to an absolute URL, then we don't have a way to check it (they're all "null"). So I don't think that works. That's why it always throws SYNTAX_ERR for "null" origins. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] implementation feedback
On Thu, 14 Jun 2012, Simon Pieters wrote: > > It's not more. But it still is. Even though images aren't required to > load at all, you still recently changed the way they load to be > compatible (http://html5.org/r/7128 ). We should also specify how videos > load to be compatible. We can do it now and get everyone to align on a > good behavior, or we can wait and do it in a few years when Web content > relies on what the market leader does, whether that's good or bad > behavior. I don't understand what behaviour it is that you think we should define. As far as I can tell, the spec is as detailed as it can be here given the range of possible implementation strategies that we need to allow. Could you give a concrete example of what you are concerned about? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Detecting eventListeners
On Fri, 25 May 2012, Xavier Ho wrote: > > We're working on a project that requires detection of registered event > listeners. Our targets are old-style "onclick" attribute bindings, > events registered via "addEventListener" (and the IE equivalent), and > other custom event libraries such as jQuery's. > > As far as we can tell, there is no way to determine if an element has an > eventListener attached to it, created via "addEventListener". There is > a sure way to remove an event (via "removeEventListener"), but we want > to enter some code path if and only if an element has an event > registered, without altering its eventListener. This is currently not > possible. > > Many discussions about this topic has been raised in the past. This > Stackoverflow answer has a good summary: > http://stackoverflow.com/questions/7810534/have-any-browsers-implemented-the-dom3-eventlistenerlist > > As far as the author could tell, this feature was never implemented due > to a lack of a use-case. We have a use-case. What specifically is your use case? The main reason this isn't supported is that it breaks the event model: the idea of events is that listeners don't affect whether something is dispatched or not. You should be able to attach a no-op listener for every event type to event event target and there should be no noticeable effect. On Thu, 24 May 2012, Glenn Maynard wrote: > On Thu, May 24, 2012 at 10:07 PM, Xavier Ho > wrote: > > > > A very common use-case is to record a mouse click on a DOM element > > which may fire an event on the page. We want to capture clicks that > > actually triggered an event, does a HTTP request, and so on, but not > > meaningless clicks on an empty region. I don't see how enumerating event listeners would let you distinguish these cases. > > That said, there is no way of surely determining if a click is > > meaningful. We check if the DOM element clicked on is a button, a link > > (has href), has onclick attribute set, and so on. However, this will > > fail on sites that binds 'click' via 'addEventListener' on a strange > > element, like a or a tag. > > This will also fail if the event handler is up the node tree. Indeed. I often just set my mouse listeners on the Window object and check the target manually (since that allows me to detect when the mouse left the target unexpectedly too), and you wouldn't be able to catch that case by enumerating listeners. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should a textarea outside of a document be immutable?
On Mon, 14 May 2012, Mounir Lamouri wrote: > > According to the HTML specifications, a textarea is mutable "if it is > neither disabled nor has a readonly attribute specified". Which means > that a textarea outside of a document is mutable. This is not the case > for an input element. > > I was wondering why there is this difference in behavior here between > those two elements. I believe both elements should be immutable when > outside of a document. The requirement for was the remnants of an attempt to define something better in the context of XBL2. I've dropped it. Elements that are not in the document, or indeed that are in a document without a browsing context, or are display:none, or children of an element that doesn't represent its contents (e.g. , , in some cases, , , etc), or scrolled off the screen, or overlapped by some other element, or any number of other cases, can't typically be edited. The spec does allow UAs to allow users to edit them in all these cases, but only requires it as a "SHOULD"; the inability for the user to reach the element at all in these cases is considered a reasonable reason to not implement the requirement in those cases. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] implementation feedback
On Wed, 9 May 2012, Simon Pieters wrote: > On Tue, 08 May 2012 18:59:29 +0200, Ian Hickson wrote: > > On Thu, 18 Aug 2011, Philip Jägenstedt wrote: > > > > > > This is true, but as long as a few big browsers implement e.g. > > > preload="none" in a somewhat compatible way, it's hard to imagine > > > page authors not coming to depend on that behavior so that it > > > becomes required for web compat. It would be interesting to know if > > > there are counter-examples, any script-visible behavior that is > > > allowed to vary greatly between implementations without causing > > > scripts to break. > > > > Images aren't required to load at all. Scripts aren't required to run > > at all. The window size is allowed to be any dimension at all. CSS > > isn't required to be supported at all. Users are allowed to apply > > arbitrary user style sheets. Users are allowed to interact with form > > controls by using the keyboard or the mouse or any other input device. > > > > All of these do break some pages. > > That CSS is optional and that users are allowed to apply user style > sheets didn't stop you from specifying the Rendering section in great > detail. Optional detail. UAs aren't required to follow that section. > Making behavior underdefined just because users should be able > to disable video loading in preferences just means that in a few years > the behavior of the market leader needs to be reverse engineered and > implemented by everyone else. I do not understand how this particular feature could end up in that state any more than the other features I list above. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] instantiating display:none plugins
On Tue, 8 May 2012, Jonas Sicking wrote: > On Tue, May 8, 2012 at 2:06 PM, Ian Hickson wrote: > > On Wed, 2 Nov 2011, Robert O'Callahan wrote: > >> One more thing. I added a "hide and show plugin with flush" test that > >> sets the plugin to display:none, causes a "layout flush" (by > >> requesting body.getBoundingClientRect()) and then sets the plugin > >> back to display:inline. On Firefox, Chrome and Opera this restarts > >> the plugin instance; on IE9 it doesn't. If you take out the flush, > >> none of the browsers restart the plugin. > >> > >> I think this should just be considered a browser bug. We don't want > >> to have to specify the timing of style and layout flushing. (We'll > >> fix this in Firefox shortly.) > > > > I just did it as a task that is queued. (This means it doesn't cause > > anything to happen if an alert() fires, because per spec alert() > > blocks the event loop. This isn't consistent with the test cases you > > gave. Not sure what to do about that.) > > This creates a pretty racy situation. Plugin instantiation is often racy anyway, since you have to download the resource to work out that it needs a plugin. > Consider a page which reacts to a state change by showing or hiding a > bunch of UI by setting display:none on an element. > > If two of these state changes happen in response to a timers, the > showing/hiding will sometimes cause the plugin to restart, sometimes > not. If the two timers end up in the queue before any of them fire then > the task to kill the plugin won't have time to run in between. If they > end up slightly further apart it will cause the plugin to get restarted. For , yeah. I suppose I could have the special case of the element obviously no longer having a plugin (e.g. it's now display:none) result in the plugin being killed sync with the event loop going back to step 1, but that's going to make the algorithm even more crazy. Are we sure we want that? For the situation is much simpler, and so it's indeed based on the event loop and not a queued task. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Search-suggestions without scripting
On Mon, 7 May 2012, Bjartur Thorlacius wrote: > On 5/5/12, Ian Hickson wrote: > > 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. > > Mixing multiple sources, such as user history and site suggestions, and > automatically performing actions upon them, such as prefetch and > prerender, should be easier for the user agent to do if the necessary > information to do so is declared, no? My point wasn't that the UA would want to add stuff, but that this kind of thing (an autocomplete widget, even one done entirely by and for the page, without the browser adding stuff) is in general more complicated than just "here's a list of completion suggestions". It's "here's five sources of data, let me rank them and figure out how to list them", or "here's a bunch of options including a rich entry with graphics", or any number of other complicated things. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Allow empty string for input type=color
On Thu, 3 May 2012, Markus Ernst wrote: > > I apologize in case this has been discussed before - the list archive > search seems to be broken right now, as it does not find any matches > when searching for "color". > > I just noticed a note in the spec of input type=color > http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#color-state-%28type=color%29: > > "Note: In this state, there is always a color picked, and there is no > way to set the value to the empty string." > > If I understand the spec correctly, entering no value defaults to > #00, thus the required attribute does not apply. What are the > reasons for this? I am sure there were good reasons to specify it this > way, anyway I don't see them right now. "Not selected" is actually very > different from "black". > > I see the following reasons for allowing the empty string: > > 1. An application might want to give the user the choice of not > selecting a color. Not specifying a color is the easiest way to state > that the default color should be used, be it black or other. > > 2. An application might want to force the user to make an explicit > selection. It may not be able to distinguish whether "black" was > explicitly selected, or the user forgot to specify a color. > > 3. Applications need to deal with the empty string anyway, as legacy > browsers show a text field. On Thu, 3 May 2012, Anne van Kesteren wrote: > > "Not selected" is not something typically supported by native color > pickers. On Fri, 4 May 2012, Shaun Moss wrote: > > The way things are done is not always the best way. Most colour pickers > are used in instances where "not selected" would make no sense. > > However, as you're designing a widget for the web that may be used by > billions of people in any number of unforeseen ways, flexibility is a > virtue, and the option to clear the field would be an improvement. If > you don't allow a "not selected" or null option, this would basically > force all colour widgets to be required fields, which may not be what > the form designer wants. > > To compare, some date pickers do not allow you to clear the field, but > some do. For the web, it's a useful feature. On Thu, 3 May 2012, Ashley Sheridan wrote: > > Would the colour pickers allow the selection of the alpha channel at the > time of choosing? If so, couldn't you allow a full transparent colour to > be used where null couldn't? On Thu, 3 May 2012, Alfonso Mart�nez de Lizarrondo wrote: > > Being able to not select a color isn't so strange. > Everyone is used to word processors, and they usually have an option to > select the color for the text and background. And among those available > colors there's an option to use the default text color or to use a > transparent background/no color. While it's true that certain colour pickers do have a "no colour" option, it is generally the case that, as with range controls, there's no "none" option in the typical UI. I expect we will add support for this at a future time, just like we will likely add support for more detailed range controls (e.g. that have a min and a max slider). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should editable elements have placeholder attribute?
On Tue, 1 May 2012, Ryosuke Niwa wrote:
>
> Would it be useful to have placeholder content attribute on elements
> that are editable? (i.e. contenteditable=true).
>
> According to the original WebKit bug 21286, this may reduce the amount
> of code authors have to write.
contenteditable="" is a low-level primitive for creating text editors.
It's not clear to me that there is much to be saved by adding a single
high level feature on top of this. You'd still have to do a ton of work to
make the editor work.
We can still make it easier to write the code, though. In fact, as far as
I can tell, it needn't be especially hard with existing specs:
[contenteditable]:empty::before { content: attr(data-placeholder) }
This wouldn't work if there's stray s, etc, but if that's the only
problem here, we can provide new selectors for it, as some people
suggested. I recommend bringing that up in the CSSWG.
On Tue, 1 May 2012, Ryosuke Niwa wrote:
>
> Great. I think the tricky part will be defining exactly how and when the
> placeholder is displayed.
>
> e.g. Should it be treated as if there is a text node in the editable
> element? Should we ignore things like "" or collapsible spaces when
> determining whether the element is empty or not?
What if parts of the element are positioned, transformed, animated, have
an SVG filter applied, constantly mutated via the DOM API, etc, etc?
On Wed, 2 May 2012, Aryeh Gregor wrote:
>
> Currently the spec isn't clear about this for , so I don't think
> it needs to specify exactly for or contenteditable either.
I strongly disagree. and are high-level constructs, so
it's fine for them to be defined by the UA's platform. But contenteditable
is a very low-level primitive. We can't just punt on how it interacts with
CSS; otherwise people will have no way to reliably make UIs with it.
On Wed, 2 May 2012, Alfonso Mart�nez de Lizarrondo wrote:
>
> Recently I wrote such a plugin for CKEditor, it can be tested here:
> http://alfonsoml.blogspot.com.es/2012/04/placeholder-text-in-ckeditor.html
> I don't think that too many people request this feature, but that might
> be simply because there are other bigger problems and they don't want to
> waste the time with these details :-)
>
> In my checks to see if the editor is empty I decided that empty means no
> real content, only a paragraph or new line, and of course every browser
> decided that clearing the content might mean a different default content
> In the end this is the check that I'm using at the moment (I didn't
> perform extensive tests, just enough to check that it seemed to work)
>
> var value = data.replace( /[\n|\t]*/g, '' ).toLowerCase();
> if ( !value || value == '' || value == ' ' || value ==
> '' || value == ' ' )
> return true;
Now there's a problem we should fix. Having five different representations
of "nothing" seems like a terrible position for us to be in.
--
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, Ian Hickson wrote:
> 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.
This is now fixed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
