Re: [whatwg] input type=number for year input
On Wed, 19 Feb 2014, Michael[tm] Smith wrote: Ian Hickson i...@hixie.ch, 2014-02-18 23:59 +: On Tue, 18 Feb 2014, Jonathan Watt wrote: I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types... This has come up a few times, but so far the use cases have not been compelling enough. This is probably the most compelling use case, but even here, I don't know that it's that compelling. I would be interested in hearing more about the locales where not using separators even for four digits is bad/suboptimal. If it wasn't for those, I would say that just not using separators for four-digit numbers would be an easy and effective solution. The following info seems relevant - http://www.thepunctuationguide.com/comma.html#numbers Most authorities, including The Associated Press Stylebook and The Chicago Manual of Style, recommend a comma after the first digit of a four-digit number. The exceptions include years, page numbers, and street addresses. To me that appears to be a strong argument that formatting of years is in fact clearly an exception, and that's compelling enough to warrant having a type for them separate from the normal number type (in which four-digit numbers would instead have a separator, to follow existing longstanding conventions). Interesting. For street addresses, we are moving in the direction of larger fields not smaller fields, so I'm not too worried about that use case. (I do know one form that looks just for a street address number, but presumably it has to handle non-numeric data anyway, as in 23A.) If that left just page numbers, I'd probably ignore it, since the use cases are pretty limited there. But years are clearly a major use case. Doing further research along these lines, it seems that it's specifically page numbers and years _that are four digits long_ that are at issue, when it comes to English: | MLA style is to use a comma in four-digit numbers except in page | numbers, line numbers, addresses, and years, unless the year has more | than four digits, such as 10,000 BCE. -- http://www.esc.edu/online-writing-center/resources/punctuation/commas/ Though some people say that applies to more than just years and page numbers: | Use commas to separate groups of 3 numbers in numbers of 5 digits or | more unless decimals are used. The comma in a 4-digit number may be | omitted. -- http://mtdesk.com/Numbers However, in other languages, as Karl showed, the pattern is different. As I see it, we have two possible paths: 1. We consider this a stylistic issue, and we add something to CSS to make it possible to control the formatting of numbers in input type=number. Then, someone doing a page-number control in English can use CSS to make it not include commas in four-digit numbers but include numbers otherwise, and so forth. 2. We consider this a semantic issue, and we add one or more new input types to handle the new smenatics. For example, we add type=year and type=page-number. We can also follow a combinations of both, providing a new control for the cases that need more than just style, and providing style for the cases that are just presentational. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: The point is that year numbers aren't really numbers in a normal sense, any more than car plate numbers, credit card numbers, product numbers, or social security numbers are. Surely they can be regarded as numbers, but so can car plate numbers and the others. On Wed, 19 Feb 2014, Smylers wrote: Except that years do actually form a sequence, and it's possible to perform maths on them; for instances, subtracting one year from another yields a duration, which is a meaningful quantity, whereas subtracting a couple of credit card numbers is completely useless. On Wed, 19 Feb 2014, Jukka K. Korpela wrote: Mathematically, you are right, but input types aren't based on general properties of quantities but on practical classification of input data. All the examples I gave, including year numbers, are normally input by typing the digits - in contrast with, say, using a color picker, a data picker, or a slider. Your annual income, when enterested into an electronic tax form, is usually input by typing the digits, but it's definitely a number. I think the only way, in western locales, that years differ from other numbers is with respect to formatting, and that's not unique to years, as Mike pointed out (c.f. page numbers). On Wed, 19 Feb 2014, Smylers wrote: There are situations where up/down arrows makes sense on years. For instance, a chart of various baby names could have a box for the year currently being displayed, and it's handy to be able to nudge that along by a year at a time to see it change, without having to manually retype the year. Or when displaying one year's tax return, with the ability to display other
[whatwg] canvas feedback
(Note: I started responding to this feedback last week, so this is missing responses to feedback sent in the last few days. Sorry about that. I'll get to that feedback in due course as well!) On Mon, 3 Mar 2014, Justin Novosad wrote: Say you create a new document using document.implementation.createHTMLDocument(), you get a document without a browsing context. This means that style and layout will never be calculated on the document. Some of those calculations are context dependent, so they can't even be resolved. Now, what about canvas elements? If JS code draws to a canvas that is in a document with no browsing context, what should happen? It should draw. In theory, anywhere in the canvas API where it depends on computed styles, it has prose saying what should happen if the computed style cannot be used. This is needed for display:none canvases, for 2D contexts in workers, and for the case you describe. For example, there is no locale for font family resolution I'm not clear on what you mean by locale here. What is the locale that a displayed canvas in a Document in a browsing context has, that a non-displayed canvas outside a Document and without a browsing context does not have? and it is not possible to resolve font sizes in physical length units unless the document is associated with a view. Why not? The canvas has a pixel density (currently always 1:1), no? My 2 cents: specifying fallback behaviors for all use cases that are context dependent could be tedious and I have yet to see a real-world use case that requires being able to paint a canvas in a frame-less document. Therefore, I think the spec should clearly state canvas elements that are in a document without a browsing context are unusable. Not sure what the exact behavior should be though. Should an exception be thrown upon trying to use the rendering context? Perhaps canvas draws should fail silently, and using the canvas as an image source should give transparent black pixels? As far as I can tell, this is all already specified, and it just gets treated like a normal canvas. On Wed, 5 Mar 2014, Rik Cabanier wrote: Testing all browsers (except IE since document.implementation.createHTMLDocument() doesn't work) they seem to handle canvas contexts with no browsing context except when you use text. Chrome crashes, firefox throws an exception and Safari draws the text with a very small scale I don't really understand why this is problematic in practice. What does a browsing context provide that is needed for rendering text that a user agent couldn't fake for itself in other contexts? We're definitely going to need text in worker canvases. On Thu, 6 Mar 2014, Justin Novosad wrote: Thanks for checking. The reason I started this thread is that I just recently solved the crash in Chrome, and I wasn't satisfied with my resolution. I just added an early exit, so Chrome 35 will fail silently on calls that depend on style resolution when the canvas has no browsing context. So now we have three different behaviors. Yay! I don't think the Safari behavior is the right thing to do because it will never match the developer's intent. I agree. The developer's intent is that text be drawn as specified in the API. Why would we do anything else? On Wed, 12 Mar 2014, Rik Cabanier wrote: On Wed, Mar 12, 2014 at 3:44 PM, Ian Hickson wrote: On Thu, 28 Nov 2013, Rik Cabanier wrote: On Thu, Nov 28, 2013 at 8:30 AM, Jürg Lehni wrote: I meant to say that it I think it would make more sense if the path was in the current transformation matrix, so it would represent the same coordinate values in which it was drawn, and could be used in the same 'context' of transformations applied to the drawing context later on. No worries, it *is* confusing. For instance, if you emit coordinates and then scale the matrix by 2, those coordinates from getCurrentPath will have a scale of .5 applied. That's rather confusing, and a pretty good reason not to have a way to go from the current default path to an explicit Path, IMHO. Transformations affect the building of the current default path at each step of the way, which is really a very confusing API. The Path API on the other hand doesn't have this problem -- it has no transformation matrix. It's only when you use Path objects that they get transformed. This happens transparently to the author so it's not confusing. I've been confused by it multiple times over the years, and I wrote the spec. I am confident in calling it confusing. For instance: ctx.rect(0,0,10,10); ctx.scale(2,2); - should not affect geometry of the previous rect ctx.stroke(); - linewidth is scaled by 2, but rect is still 10x10 It's confusing because it's not at all clear why this doesn't result in two rectangles of different sizes: ctx.rect(0,0,10,10); ctx.scale(2,2); ctx.stroke
Re: [whatwg] Media sink device selection on audio/video
On Mon, 7 Apr 2014, Harald Alvestrand wrote: On 04/02/2014 07:52 PM, Ian Hickson wrote: On Mon, 3 Mar 2014, Ami Fischman wrote: Looks like we're back in business: Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. Would it make sense to group the access to sinks in with access to sources - that is, this page wants access to your cameras, microphones and audio output devices? (either on a per-device basis or as an all-or-nothing prompting) Wouldn't that be an implementation detail? When I was first desigining the API for WebRTC (years ago, before it got rather unceremoniously forked by the W3C), the security design I had come up with was basically that the UA would show a panel of devices, and the user would drag-and-drop them into the page to give the page access to them. (Or equivalent UI, e.g. tapping on the relevant device icons to activate them for the page.) This would let me, as a user, specify that on my laptop YouTube can play video on my TV (assuming we extend this stuff to support video over Miracast/AirPlay/WiDi/DIAL/Chromecast/DLNA) while not allowing it to send audio to my bedroom, while simultaneously having Amazon's Cloud Player sending its music to my bedroom, but not allowing it to use my microphone. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Mon, 7 Apr 2014, Harald Alvestrand wrote: The consensus opinion at WebRTC and MediaCapture seemed to be that the ability to let an app say which of these 5 microphones do you want? is more amenable to creating good apps than leaving this UI to the browser chrome. Seems to me that the privacy aspects (the fingerprinting vulnerabilities from exposing this data), and the abuse aspects (giving hostile sites the ability to access all the user's devices if any are made available) would trump this. Surely we can rely on user agents to provide nice UIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
On Sun, 6 Apr 2014, Steve Faulkner wrote: On 6 April 2014 05:11, Ian Hickson i...@hixie.ch wrote: On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Platform conventions for disclosure type widgets vary, on windows for example, the current implementations match the convention. The conventions on Windows are all over the place: http://msdn.microsoft.com/en-us/library/windows/desktop/aa511487.aspx ...but I doubt that this matches any of the Windows conventions: | when the summary element includes other interactive elements (as it is | allowed to), clicking on them results in the details element being | opened/closed details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, how so? All that should be necessary is: details summary Foo /summary ... /details Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. with the current definition how do authors provide a label for the disclosure widget when summary also contains controls with labels? If doing so matches the platform conventions, any non-interactive text in the summary would open the widget. in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
On Mon, 7 Apr 2014, Steve Faulkner wrote: All that should be necessary is: details summary Foo /summary ... /details Adding two attributes and an elements is thus more complicated than necessary. This seems pretty unambiguous to me. for the case details summary Foo input Bar /summary ... /details whats the disclosure label? The text Foo, a text field, and the text Bar. If by disclosure label you mean the parts which, on certain platforms, when clicked, would toggle the open state, then that depends on the platform, but I would expect the Foo and Bar text to be good candidates, since they're otherwise inert. what about? details summary labelinput Bar /label/summary ... /details Here there's no non-interactive text, so there's no text to target. in the absence of browser making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. how is an author supposed to do this? The author isn't supposed to do this. The whole point of semantic controls like this is that the user agent is the one that picks the user interface. does this also extend to the author being able to provide an accessible name for the control? Should there be a particular need for an accessible name for the details control, ARIA can be used to set the name. But I must admit to not understanding why you would need that in practice, if the page is well written. (I find most pages that use accessible labels in situations such as this tend to be poorly written for non-AT users.) Once we start talking about custom widgets, we're in the space of Web components, at which point the author can do whatever the author wants. yeah, its a shame that the design of some html features don't provide the flexibility to allow authors to fix user agent specific design deficits without recourse to web components Why is avoiding Web components a goal? That's like saying it's unfortunate that nails don't provide enough flexibility to be driven into walls without recourse to a hammer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] summary/details - proposal
On Sat, 5 Apr 2014, Steve Faulkner wrote: The summary itself is not interactive, so only the triangle provides the actionable control. The spec doesn't disallow making clicks on (non-interactive) parts of the summary defer to the disclosure triangle. Browsers should just match platform conventions, where applicable, and otherwise make whatever is considered the best choice for users (such as making such content also trigger the disclosure triangle). Given that what we want to provide for the use case of having controls inside the summary, after discussion around the issue, I have proposed the following: details summary id=x label for=xFoo/label /summary ... /details That's way more complicated than necessary for authors, not to mention all the problems it would cause with the existing label definitions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Effect on window.opener when navigating an existing window using window.open
On Mon, 3 Mar 2014, Bob Owen wrote: The spec [...] seems to be fairly clear that if an existing window is navigated using window.open, by a browsing context that is not the original opener, then window.opener should remain unchanged. Currently, Trident (and incidentally Presto) seems to have the correct behaviour, but Blink, WebKit and Gecko all change window.opener to the window of the browsing context that has just caused it to navigate. I believe this to be a very long standing difference (10 years for Gecko and Trident) I am proposing to change Gecko to match the spec, but I was advised to raise the issue here before going ahead. Do people agree that window.opener should remain unchanged in this circumstance? Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Having opener be the actual opener seems pretty intuitive to me; if there's no compat need to do otherwise, it seems like a reasonable choice. Is there a security reason to prefer the latest navigator? (At the time the spec was written, it was 2v2; the 1v3 situation we have now is the result of Presto going away and Blink forking from WebKit.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Mon, 3 Mar 2014, Ami Fischman wrote: Looks like we're back in business: Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] More effective model for handling resources
On Thu, 13 Mar 2014, Tingan Ho wrote: Almost all web developer I know use externally linked CSS resource in their web projects. That means that the browser needs to (1) request the html page (2) parse the html (3) request for the CSS resource that is linked from the html document. The problem with externally linked resources is point three. It needs to make another request for the CSS resource. There is a solution to this problem and that is to inline the CSS. Though that would yield another problem: all subsequent page request will become bigger. I believe this is being handled by the next-generation transport protocols (SPDY or whatever it's called now). I recommend approaching the relevant groups to check that your precise case has been handled. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inverse property mechanism for Microdata?
A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemscope itemtype=http://schema.org/LocalBusiness; div itemprop=containedIn itemscope itemtype=http://schema.org/LocalBusiness; itemid=.../div h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div Is this not suitable for schema.org? Or is it just too much markup? It's in the clever-but-fragile category, I'd say. So yes, a bit too much markup. In English this is saying something like We're describing a LocalBusiness whose global ID is [xyz]; it has certain name, description, telephone properties given here. There is also a LocalBusiness that is containedIn a LocalBusiness whose global ID is [xyz]; this [other] LocalBusiness has the following name, description, telephone etc properties Just as in the English, it is rather easy to lose track of which LocalBusiness we're talking about. I think you overstate the complexity, but ok. That is another option, similar to the parenthetical itemid= note above -- you could just have the vocabulary define that for every property whose value is an item, the item type that that property can point to has another property with the same name plus a fixed suffix, like -inv, that inverses the relationship. [...] This is easier to understand than itemref, but still involves creating 100s of additional properties instead of just one new piece of syntax. What do you mean by creating additional properties here? It's relatively trivial to define these with one sentence, you don't need to actually list them or anything. Implementing support is similarly easy, as far as I can tell -- you just check for the suffix or prefix and handle it accordingly. Re you don't need to actually list them, this effectively creates two classes of property. Real ones, and fake/pseudo properties which we're pretending exist so that we can re-use a piece of syntax that expects a property name. Once these pseudo properties are released into the wild, they'll show up as if they were real. They would be real, I'm just saying that documenting them and implementing them is somewhat trivial. What we want to avoid is saying things like: You can use itemprop='containedIn-rev' to indicate a property that means the inverse of containedIn. However this is not a first class schema.org property, and should not be used other syntaxes (JSON etc), data dumps, APIs etc. You should canonicalize x containedIn-rev y into: y containedIn x., ... Why wouldn't it be a first-class property? It could trivially be so. The implementation is easy, whatever the vocabulary it's used in. If you do want to go with a new property, just use the name you would want in the spec. I weakly recommend itemprop-up, which is the most intuitive name I've seen so far for this, but if you find a better name just use that. I guarantee that I won't make the spec conflict with whatever you use, as long as you tell me what it is. :-) Assuming that it works well, then we would just update the spec to use that term directly, retroactively making the experimental content conforming. Thanks! I'll discuss this thread with the schema.org team. My guess is that there's still a strong preference for a new property, and we'd be happy to avoid using data-*. If I understand right, the outstanding area of discussion/confusion is whether there are cases beyond simple DOM element containment where we might want to use an inverse itemprop construction (even though we can see how itemid everywhere might also be used). If we're only using element hierarchy then itemprop-up could work. Did you reach any conclusions in these discussions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Various autocomplete= topics
On Wed, 5 Mar 2014, Qebui Nehebkau wrote: On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson i...@hixie.ch wrote: I think the arguments you've presented so far suggest address-levelN for N=1..4, with 4=region and 3=locality, is probably the simplest thing to do. I was hoping there might be other people with opinions, to give us different perspectives on this, but it seems nobody else cares. :-( Since you asked, I think the whole endeavour (of trying to tokenise an address) is pointless and should be abandoned outright. :) In principle I agree, but in practice I think we have to work with the reality that that is what people are doing. Short of my ideal of *only* offering the full address (as used on a label) as an opaque string, I think it would be most reasonable to consider the 'locality' field itself to be a fully-specified opaque string, including whatever information is necessary to completely identify the location from the region level (such as the prefecture and district), rather than a single level. Failing all that, I would at least prefer for the fields to have names instead of abstract numbering, because people are likely to be confused about the order, no matter which end is the 'widest'. It also seems more intuitive, to me, for the 'locality', as, after all, 'local', to be the most specific level. Would people not be confused by names in the same way? On Wed, 5 Mar 2014, Qebui Nehebkau wrote: Right, impose, certainly not. But, perhaps, (one hopes,) encourage? Or at least refuse to explicitly support anything else. Does autocomplete *need* to support people who are already doing it wrong? But I'm probably just being too utopian; it happens. Well if we don't support pretty much every form out there, the feature isn't particularly useful. On Tue, 4 Mar 2014, Kevin Marks wrote: address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. Yes, this alternative works, but in my opinion is not preferable. Because these words don't really mean anything. Nor do numbers. I think we don't really have any chance of giving meaning to the names here either way. On Tue, 4 Mar 2014, Evan Stade wrote: dependent-locality and locality have a fairly precise meaning in the UK. Also in a natural-language conversation, if you ask me what region of the country I live in, I'd say New England, the Midwest, or some such; certainly not the state where I reside. The descriptions for these tokens are currently pretty specific, for example they say a city would be a locality. But this is not true for Beijing or some other cities. To fix the descriptions, we'd have to change them to something like region: the highest level administrative region below country in the address and locality: the second-highest level administrative region below country in the address, sub-locality: the third-highest level administrative region [...]. With you so far. At this point, one wonders why the tokens aren't just [something]1, [something]2, etc. I don't understand how you get there. Why would you wonder this? address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name I don't understand why you think authors will think they need to include subregion, but won't think they need to include address-level3. I think they'll assume subregion returns something for the US if it's sandwiched between region and locality, because county is in between state and city. But in reality, subregion will return nothing. But why does this not apply to the numeric version? Having synonyms is really bad. It leads to huge amounts of confusion. This is why I'm trying to avoid having synonyms for the address-level* stuff. We should definitely not add some just to introduce a slightly better name. My suggestion is to change the address-line1 to street-address-line1, not to have synonyms. Chrome would then support address-line1 for a limited period of time, but outside the spec. There's no outside the spec. The spec tries to describe reality. If you implement something, then that's the reality, and that's what the spec would say, and therefore we'd have
Re: [whatwg] Effect on window.opener when navigating an existing window using window.open
On Wed, 2 Apr 2014, Bob Owen wrote: Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Thanks for getting back to me Ian. No, no other feedback. I have a patch for it, but haven't pursued it any further. I could investigate putting the change in for Firefox Nightly, if you think that might help with finding any compat issues. Well as far as I'm concerned, I would encourage you to try to converge on the spec behaviour. If it turns out there are compatibility issues, that would be good to know. If not, then at least we win more interoperability. I can also see that both pieces of information (original opener and last navigator) might be useful. So, maybe the other could be added either way. I haven't heard any author demand for it, so I haven't added it, but indeed, if this is something authors have a use for, we could add it. It's worth noting that there are many many ways to navigate a browsing context beyond window.open(), e.g. a target=, window.location, drag-and-drop of a link, window.history.go(), etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Document.title for SVG documents
On Tue, 4 Feb 2014, Cameron McCormack wrote: Ian Hickson wrote: I'm all for handling it in one place. What precisely do you want the behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- the first svg:title element may come after the firsthtml:title element, and vice versa. Also consider when one or the other is primary but the relevant element is absent.) OK, how about: if the document element is an html:html, we choose the first html:title in document order; if the document element is an svg:svg, we choose the first child svg:title of the document element; otherwise, null. This still is going to produce incorrect results for things like: !DOCTYPE html svg foreignObject titleblah/title /foreignObject /svg but arguably you shouldn't be using title in there anyway. It doesn't seem useful to hit that element. It's not the (SVG) document title, after all. I ended up going with: - if it's an SVG document, use the first title child of the root element - if it's an HTML document, use the first title element in tree order (that's what it used to be) For setting it uses the same element, unless there isn't one, in which case: - if it's an SVG document, append an SVG title to the root element - if it's an HTML document, append a title to the head Hopefully that's compatible enough. Let me know if you need something different. On Mon, 3 Feb 2014, Jonas Sicking wrote: An even simpler solution would be to say we choose the first html:title or svg:title in document order. That has the nice property that we align SVG and HTML more. This seems to not quite match the SVG semantics, unfortunately. On Wed, 5 Feb 2014, Simon Pieters wrote: Is there a situation in which it is conforming to use html:title outside the head in a document where the root is html:html? In math:annotation-xml? You can certainly imagine a compound document format containing entire HTML subdocuments, html, head, title, and all. I'm not sure that's possible with just SVG and HTML currently though. (Maybe MathML, indeed.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] microdata questions
On Mon, 10 Feb 2014, Eric Devine wrote: 1. Section 5.5.1 of the Microdata spec prescribes how microdata should be respresented as JSON, but it does provide a MIME type. I'm writing a REST API that I would like to be able to return JSON in microdata format, but I need the client to explicitly request this via the HTTP Accept header. The main concern is to know when to return plain properties as an array with one element. As a general rule I would recommend against using Accept headers to do anything. You're better off making the JSON data its own resource, IMHO. Having said that, as you noted in a later e-mail, the MIME type suggested by the HTML spec is application/microdata+json. http://whatwg.org/html#application/microdata+json 2. Section 5.2.4 does not provide a way to apply a property value to the value attribute of an option element. Is this an oversight, or is there simply not a convincing enough use case for the need? There's not any way currently to make for controls map to microdata. It's not clear exactly what it would mean. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Document.title for SVG documents
On Tue, 1 Apr 2014, Jonas Sicking wrote: On Tue, Apr 1, 2014 at 11:55 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Feb 2014, Jonas Sicking wrote: An even simpler solution would be to say we choose the first html:title or svg:title in document order. That has the nice property that we align SVG and HTML more. This seems to not quite match the SVG semantics, unfortunately. Does it break existing content? If not, why not ask the SVG spec to be changed? The thread was started by one of the SVG spec editors after all. Dirk and heycam's replies to your original e-mail here suggest that this is not really viable. I mean, it'd be like changing document.title in HTML to point to the first title= attribute in the document if it came before the first title. Anyway, what the spec ended up saying is in some ways even simpler, since it only looks one level deep for SVG rather than doing a deep tree search. (Is this the kind of change that you would have liked pre-flighted? I can revert the change and put out an announcement if you like. I'm not yet sure I exactly understand what kinds of changes fall into this category.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] keygen and X509 client cert mime type
On Tue, 25 Feb 2014, henry.st...@bblfish.net wrote: The keygen form element does a great job of specifying how the browser creates a public/private key pair, stores the private key in it's local keystore. When the control's form is submitted, the private key is stored in the local keystore, and the public key is packaged and sent to the server. It is clear that the intention is for the server to send back a certificate built from the public key. What I can't find is what the mime type of the returned certificate should be. I have been using `application/x-x509-user-cert` which seems to work for Safari, Firefox, Opera . But I think that is not an officially supported certificate type. application/pkix-cert seems to be that after looking it up on iana. I ended up posting a bug report for Android on that. http://code.google.com/p/android/issues/detail?id=66342 But now I have to check for each browser which is the type all browsers support. To avoid people having to do this research again and again, perhaps it would be worth specifying a mime type that all browsers do/must support in the HTML5 spec? On Wed, 26 Feb 2014, henry.st...@bblfish.net wrote: (1) most browsers currently understand the mime types (a) application/x-x509-user-cert (b) application/x-x509-ca-cert (c) application/x-x509-email-cert ( I have only verified (a) btw. I am assuming the others also support (b) and (c) ) as specified here https://wiki.mozilla.org/CA:Certificate_Download_Specification (2) the above mime types are not registered http://www.iana.org/assignments/media-types/media-types.xhtml So really either the old mime types should be registered, or they should be mentioned as being in use but deprecated and people should be guided towards the application/pkix-cert I wouldn't worry too much about registered vs not registered. If the registry doesn't match the implementations, the registry is buggy. On the other hand, I also don't want to get into the business of specifying this stuff myself. I've added a link to the above MDN page to the keygen section. If there is ever something more canonical (and yet still useful and accurate), let me know and I'll update the spec. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Locale Preferences API
On Tue, 17 Dec 2013, Mark Callow wrote: On 2013/10/15 6:24, Marcos Caceres wrote: On Friday, July 26, 2013 at 8:14 PM, Marcos Caceres wrote: This document proposes an extension to HTML's `Navigator` interface to enable dynamic localization of content. The idea is to expose to script the language tags that represents the user's locale preferences (akin to the language tags that are normally sent with HTTP's `Accept-Languages` header). My question is will anyone use it? In my experience most web sites ignore the Accept-Languages header. I am continually being served pages in Japanese even though English is the top language in my accept list. It's a good question. There are only two reasons I can think of for this happening: * sites are choosing the language based on the location of my IP address. This is almost certainly the cause. * sites are choosing the language based on my OS locale setting. though I'm pretty sure I've been served Japanese pages on systems where it is not set to JA plus I don't know if that is visible to either server or application. I don't think this is visible to the page currently, except indirectly via navigator.language, so if your browser is configured to only report English, that's all the page should see. The feature requested in this thread did end up being added to the spec: http://whatwg.org/html#language-preferences It's basically just an array version of navigator.language, and the spec suggests using the same list as for Accept-Language, so it doesn't really provide anything new, it's just more convenient. It's true that Accept-Language doesn't seem to have been widely used. The feature was primarily added due to requests from implementors. I don't know what we can do to cause authors to rely on this API and its siblings rather than on IP geolocation. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inverse property mechanism for Microdata?
. [...] This is easier to understand than itemref, but still involves creating 100s of additional properties instead of just one new piece of syntax. What do you mean by creating additional properties here? It's relatively trivial to define these with one sentence, you don't need to actually list them or anything. Implementing support is similarly easy, as far as I can tell -- you just check for the suffix or prefix and handle it accordingly. I don't really understand why 'itemprop-foo=bar' would be any better than 'itemprop=bar-foo'. Can you elaborate on this? It seems like it would essentially be identical in practice. There are significant costs to introducing a new language feature here, I think, so we should definitely consider this alternative carefully before dismissing it. Would a data- attribute be an appropriate way to indicate an experimental/proposed attribute? And then if it works out well perhaps a real microdata attribute could be added later? e.g. data-itemprop-inverse=alumni ... If you do want to go with a new property, just use the name you would want in the spec. I weakly recommend itemprop-up, which is the most intuitive name I've seen so far for this, but if you find a better name just use that. I guarantee that I won't make the spec conflict with whatever you use, as long as you tell me what it is. :-) Assuming that it works well, then we would just update the spec to use that term directly, retroactively making the experimental content conforming. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Grouping in canvas 2d
On Wed, 4 Dec 2013, Jürg Lehni wrote: Implementing [layering/grouping] would help us greatly to optimize aspects of Paper.js, as double buffering into separate canvases is very slow and costly. Can you elaborate on what precisely the performance bottleneck is? I was looking through this thread but I can't find a description of the use cases it addresses, so 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] Bicubic filtering on context.drawImage
On Mon, 9 Dec 2013, Tingan Ho wrote: I'm a web developer in need of bicubic filtering on context.drawImage. I use to crop and scale images on the web using canvas. And I noticed that quality when you scale down very much is very bad on canvas. Do you need bicubic filtering specifically, or would any high quality resizing algorithm work for you? I scale down images using context.drawImage. There is no way for me to opt in for which filter method to use. I thought it was a bug first, because I thought context.webkitImageSmoothingEnabled did the job. But it didn't. So I filed a bug for chrome. But they suggested me to email you guys. https://code.google.com/p/chromium/issues/detail?id=326640 If the bug is that Chrome resamples the image in an ugly way, then that's a bug with Chrome. As the bug says, browsers are allowed to pick whatever algorithm they want -- it's a quality-of-implementation issue. But if the result is ugly, that's a low quality implementation. On Mon, 9 Dec 2013, Tingan Ho wrote: [...] it kind of make sense if you set imageSmothingEnabled to true in the context object, that all down-scaling should use bicubic resampling(I haven't tried yet, but I think the scale use bicubic sampling). I think it is is a miss in the specification that the method drawImage doesn't use bicubic resampling. It is a method of the context objext on des down-scaling. Well, when scaling down, nearest-neighbor interpolation doesn't make sense. So the false value doesn't really make sense when scaling down. So browsers have to pick an algorithm. Which they pick (and how it's implemented, etc) decides the quality of their implementation. On Mon, 9 Dec 2013, Oliver Hunt wrote: I’m not sure why you have a bias towards bicubic filtering as there are many different scaling filters that can be used. Lanczos is better than bicubic in many (most?) cases. Spline scaling can also do a good job, as can fractal interpolation. There are even specific scaling systems like Sal which are designed for upscaling sprites, and do a better job at the specific task than anything else (IIRC this is frequently used by the various old console emulators) This is why the spec currently doesn't specify an algorithm. On Mon, 9 Dec 2013, Tingan Ho wrote: That would be even better. At least if I can opt-in for the one I want. But I think most developers also don't want to dive into this algorithms, so it would be good to have default values that perform well. right now I don't know exactly what all browser vendors are using, maybe bilinear? But it result in very poor image quality. That's a quality-of-implementation bug with the browsers, not a spec bug. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2 requests for drawSystemFocusRing
On Mon, 16 Dec 2013, Rik Cabanier wrote: Ian wrote: On Wed, 2 Oct 2013, Rik Cabanier wrote: I don't understand. If the path that is active during drawCustom/SystemFocusRing is off screen and the element is focused, the browser will scroll to that area. drawCustomFocusRing() and drawSystemFocusRing() shouldn't cause anything to scroll. That would be very confusing, IMHO. (When would you scroll? Consider the case of the control originally being off-screen on purpose, and animating into position. You want the focus ring drawn the whole time, and the zoom to follow it maybe, but you only want to scroll once, at the start, to the location that it will have at the end.) We want to scroll if the element is focused and the area that is described by the current path is offscreen. This should follow CSSOM View's definition of scrolling [1]. Doing this in a way that's in any way related to draw*FocusRing() doesn't make any sense. However, it definitely makes sense for the browser to inform the page when the AT wants to scroll to a hit region, and this is the topic of this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24748 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Fri, 7 Feb 2014, Justin Novosad wrote: Current text: If the point (x0, y0) is equal to the point (x1, y1), or if the point (x1, y1) is equal to the point (x2, y2), or if both radiusX and radiusY are zero, then the method must add the point (x1, y1) to the subpath, and connect that point to the previous point (x0, y0) by a straight line. With arcTo, the first point (x0, y0) may have been added to the current subpath using a different CTM. So to bring it into the local space of the current primitive, we need an invertible CTM. What I don't understand is why you can't draw the curve in the transformed space instead of the 1:1 coordinate space. You have to transform it eventually, right? And the points will end up simply transformed. So you can easily compare the points in the transformed space. All the transforms are affine, so what's a straight line isn't impacted. Can't you just draw the transformed arc instead of first drawing the circular arc and then transforming it? Maybe what I'm saying is obviously dumb for some reason, but I'm not understanding why, if so... (not that I'm a graphics guy, obviously). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Canvas hit regions
I've done some more work on the spec for event rerouting for hit regions, based on the feedback sent to this list. On Wed, 5 Mar 2014, Robert O'Callahan wrote: On Wed, Mar 5, 2014 at 12:53 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 Feb 2014, Rik Cabanier wrote: For instance, if the fallback is an edit control and the user drag-selects some text on the canvas, is it expected that this text is also selected in the edit control? You can't validly include a text field in canvas fallback precisely because of this kind of thing. See: http://whatwg.org/html#best-practices The question remains: what should happen in Rik's example? If the control is a text edit control, the event isn't rerouted. This was always the intention (hit regions couldn't be set for text edit controls), but there was a loophole before, where you could register a hit region for one kind of control and then change that control to be something else. I've adjusted the spec to close that loophole. Event retargetting now explicitly applies to the control represented by the region, which is always null if the given control is now a text field. More generally, is this event rerouting supposed to be able to trigger browser default event handling behavior, or only DOM event dispatch? As it was specified, I don't see how it could trigger default actions of anything other than the canvas and its ancestors. The canvas hook ran in the middle of the When a pointing device is clicked, the user agent must run these steps algorithm, which refers to the origin target, not the rerouted target. I've now changed this so that it does in fact trigger the default action if applicable. On Wed, 5 Mar 2014, Robert O'Callahan wrote: The problem is that if these retargeted events can trigger default browser behavior, the browser has to be able to compute the position of the event relative to the new target DOM node, and it's not clear how to do that. I've made it explicit that the elements that can get clicks targetted to them only include elements that don't have subregions. In particular, image maps and image buttons are excluded. On Tue, 4 Mar 2014, Rik Cabanier wrote: On Tue, Mar 4, 2014 at 8:30 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 4 Mar 2014, Rik Cabanier wrote: So what would you do in the case where you start two touches on different regions, then move them at the same time to two other different regions at the same time? What would you put in the touchmove event's object? The touches attribute [1] of the touch event would contain 2 touch elements. Each touch element would have as target the canvas element and contain the id of the hit region. Oh so it's not the TouchEvent object you think should be adjusted, but the Touch object itself? (I'm assuming that's what you are referring to when you say touch element.) Presumably we would just set the region at creation time, like the target attribute, right? I've specced this. On Mon, 10 Mar 2014, Rik Cabanier wrote: Currently, the specification states that if you create a region and then create another region that completely covers region, the first region is removed from the hit region list [1] This is a complex operation that involves either drawing the regions to a bitmaps and counting pixels, or path intersection. There's two trivial ways to implement this, depending on whether the hit regions are backed by a bitmap (the simplest and fastest solution but uses a lot of memory) or a region list (slower, but much more memory efficient). In the case of a bitmap, you just draw on the new region, and the old region is no longer in the bitmap, so it's trivially gone. In the case of a list, you put the new region ahead of the old region so that you never actually get around to checking the old region. In the latter case you would want to run compression algorithms every now and then to filter out old regions that no longer matter (though in most cases that would probably not be an issue since I expect most people will clear the whole canvas every frame, which can be trivially detected and can just cause the whole list to clear). It is also unintuitive because an author might expect that he could remove the second region and still have the first region active. That would be inconsistent with how canvas works. Canvas is an immediate- mode API. If you draw on the canvas, and then clear it, you don't get back what was there before. On Tue, 11 Mar 2014, Rik Cabanier wrote: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/thread.html#36556 It looks like that thread never came to a conclusion. Is there anything specifically that was raised in that thread that you think hasn't been responded to? The arguments against using a bitmap presentation still stand: - it will be too expensive to keep an actual copy of the canvas pixels in memory to do hit
Re: [whatwg] canvas context alpha attribute
On Wed, 12 Mar 2014, Rik Cabanier wrote: About a year ago, Google and mozilla proposed the alpha attribute as an option when you create the canvas context. The wiki explains the feature very well. [1] Since then, Google has implemented and shipped this [2][3]. There is a proposal to implement [4] and a patch [5] for firefox. An author can feature test by setting alpha to false and reading a pixel in the context. If the pixel comes back with an alpha of 0, it means that it is not supported. Could this be added to the HTML specification? [6] It's being tracked here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23515 It's awaiting interest from a second vendor. It's not clear to me from the Mozilla bug whether Mozilla engineers actually support this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] canvas context alpha attribute
On Wed, 12 Mar 2014, Rik Cabanier wrote: It's being tracked here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23515 It's awaiting interest from a second vendor. It's not clear to me from the Mozilla bug whether Mozilla engineers actually support this. See roc's reply here: [Clarified on IRC to be: https://groups.google.com/forum/#!topic/mozilla.dev.platform/5i8H-xKGtEg ] Cool, thanks. I've updated the bug so that it's on my radar again. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Canvas and Paths
On Thu, 28 Nov 2013, Rik Cabanier wrote:
On Thu, Nov 28, 2013 at 8:30 AM, Jürg Lehni li...@scratchdisk.com
wrote:
I meant to say that it I think it would make more sense if the path
was in the current transformation matrix, so it would represent the
same coordinate values in which it was drawn, and could be used in the
same 'context' of transformations applied to the drawing context later
on.
No worries, it *is* confusing. For instance, if you emit coordinates and
then scale the matrix by 2, those coordinates from getCurrentPath will
have a scale of .5 applied.
That's rather confusing, and a pretty good reason not to have a way to go
from the current default path to an explicit Path, IMHO.
Transformations affect the building of the current default path at each
step of the way, which is really a very confusing API. The Path API on the
other hand doesn't have this problem -- it has no transformation matrix.
It's only when you use Path objects that they get transformed.
So this is not how most implementations currently have it defined.
I'm unsure what you mean. Browser implementations? If so, they
definitely do store the path in user coordinates. The spec currently
says otherwise [1] though.
I'm not sure what you're referring to here.
It would be a very fast way to set a cached path in the graphics state
What would the purpose of this be? You can just pass the path to the
relevant functions instead, no?
Another use case is to allow authors to quickly migrate to hit regions.
ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill();
... // lots of complex drawing operation for a control
ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke();
To migrate that to a region (with my proposed shape interface [1]):
var s = new Shape();
ctx.beginPath(); ctx.lineTo(...); ...; ctx.fill(); s.add(new
Shape(ctx.currentPath));
...
ctx.beginPath(); ctx.lineTo(...); ...; ctx.stroke(); s.add(new
Shape(ctx.currentPath, ctx.currentDrawingStyle));
ctx.addHitRegion({shape: s, id: control});
Why not just add ctx.addHitRegion() calls after the fill and stroke calls?
On Fri, 6 Dec 2013, Jürg Lehni wrote:
Instead of using getCurrentPath and setCurrentPath methods as a
solution, this could perhaps be solved by returning the internal path
instead of a copy, but with a flag that would prevent further
alterations on it.
The setter of the currentPath accessor / data member could then make the
copy instead when a new path is to be set.
This would also make sense from a a caching point of view, where storing
the currentPath for caching might not actually mean that it will be used
again in the future (e.g. because the path's geometry changes completely
on each frame of an animation), so copying only when setting would
postpone the actual work of having to make the copy, and would help
memory consummation and performance.
I don't really understand the use case here.
On Fri, 29 Nov 2013, Rik Cabanier wrote:
On Mon, Nov 25, 2013 at 3:55 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 28 Sep 2013, Rik Cabanier wrote:
On Fri, Sep 27, 2013 at 2:08 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 5 Sep 2013, Rik Cabanier wrote:
On Thu, Sep 5, 2013 at 3:22 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 10 Aug 2013, Rik Cabanier wrote:
I was wondering if this is something that happens in Flash
as well. It turns out that there's an option called
hinting: Keep stroke anchors on full pixels to prevent
blurry lines. [...]
I think canvas should have a similar feature...
Can you elaborate on how exactly you would want this to work?
How would you avoid the alignment and distortion problems when
applying this to anything less trivial than a rectangle?
Basically, this would *just* move the control points and the
width of paths so the strokes are always aligned to the pixel
grid (This would take pixel density and transformations into
account). After this, you would draw as usual.
Can you define aligned to the pixel grid?
If I have a line from x1,y to x2,y, followed by an arc from x2,y
back to x1,y with radius r, what should happen and why?
Align the anchor points of all the segments. Don't change any of the
anti-aliasing behavior.
How does this differ from simply always using integers for
coordinates?
It would simplify the process for the developer as it might be difficult
to determine what an integer coordinate is, especially if there is a
complex CTM in effect. For instance, if the scale is .5, you'd have to
round to a multiple of 2.
I don't really understand when the snapping happens in this proposal.
Consider a rotation transformation matrix. How exactly does the snapping
work? In a space that's transformed by 45 degress, how would lines drawn
at 44, 45, and 46 degrees to the horizontal, all
Re: [whatwg] Simplified picture element draft
On Tue, 7 Jan 2014, Yoav Weiss wrote: On Tue, Jan 7, 2014 at 6:20 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/7/14 12:01 PM, Yoav Weiss wrote: I'd love to get some more details regarding that. I'll start a mozilla.dev.platform thread on the subject, since it's Gecko specific. It's actually not entirely Gecko-specific. Consider a display:none iframe. How should viewport-size-related media queries be evaluated in such a thing? The specs don't define it, as far as I can tell. In fact, the specs don't actually define anything useful for the viewport of a framed document at all, as far as I can see. CSS just assumes a viewport exists, and HTML doesn't define anything about frames setting up a viewport for the document inside them... But say they defined it. How would the viewport of a display:none iframe be defined, exactly? Last I checked, UAs just end up doing wildly different things in this situation. I agree that iframes complicate things, since the parent document's external CSS can modify their viewport dimensions, so there's an inherent race condition there. It's sort of a race, but it settles, right? Since this case is not the majority case, we could bail out of it by delaying the iframe's subresource loading that rely on viewport dimensions until the parent's layout is considered done (e.g. all its head CSS was parsed and applied) The iframe can change dimensions long after that, still (e.g. if it's sized based on other content later in the page, as in a complex table). I'm sure browsers can optimise a bit here, but it's not clear to me that there's anything we need to explicitly require. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Wed, 5 Mar 2014, Rik Cabanier wrote: Testing all browsers (except IE since document.implementation.createHTMLDocument() doesn't work) they seem to handle canvas contexts with no browsing context except when you use text. Chrome crashes, firefox throws an exception and Safari draws the text with a very small scale [1] The spec actually defines what happens with fonts when you don't have a defined computed style: # If the computed values are undefined for a particular case (e.g. because # the font style source object is not an element or is not being # rendered), then the relative keywords must be interpreted relative to # the normal-weight 10px sans-serif default. This is needed for text rendering in Workers, if nothing else. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [2D Canvas] Do canvases in documents without a browsing context need to be rendered?
On Thu, 6 Mar 2014, Justin Novosad wrote: On Thu, Mar 6, 2014 at 1:17 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Mar 2014, Rik Cabanier wrote: Testing all browsers (except IE since document.implementation.createHTMLDocument() doesn't work) they seem to handle canvas contexts with no browsing context except when you use text. Chrome crashes, firefox throws an exception and Safari draws the text with a very small scale [1] The spec actually defines what happens with fonts when you don't have a defined computed style: # If the computed values are undefined for a particular case (e.g. because # the font style source object is not an element or is not being # rendered), then the relative keywords must be interpreted relative to # the normal-weight 10px sans-serif default. This is needed for text rendering in Workers, if nothing else. Ah! So that clears it up... almost. How do we interpret that for Path objects? Does adding text to a path count as a case where font style is undefined, or do we defer and resolve the font style when the path object is drawn to a canvas? Depends on the Path object. There's a font style source object defined for anything that might draw text (if I didn't screw it up), and that's what decides what you should be rendering relative to. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] new constructor method for Path2D
On Wed, 5 Mar 2014, Rik Cabanier wrote: To work around this, we could add a couple of constructor methods to the 2D context: Path2D createPath(); Creates a new empty Path object [...] This used to be how many Web APIs worked, but over the years we've received enormous volumes of feedback to the effect that constructor-based APIs are way better than factory-based APIs. Is there no way we could at least have all the canvases within a Document in Firefox use the same backend? It would be really unfortunate to have to use factories here to get around an implementation detail in one browser. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] new constructor method for Path2D
On Wed, 5 Mar 2014, Jeff Muizelaar wrote: On Mar 5, 2014, at 5:34 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Mar 2014, Rik Cabanier wrote: To work around this, we could add a couple of constructor methods to the 2D context: Path2D createPath(); Creates a new empty Path object [...] This used to be how many Web APIs worked, but over the years we've received enormous volumes of feedback to the effect that constructor-based APIs are way better than factory-based APIs. Is there no way we could at least have all the canvases within a Document in Firefox use the same backend? It would be really unfortunate to have to use factories here to get around an implementation detail in one browser. The choice of backend depends on the size of the canvas. So it wouldn’t be easy to have all canvases within a document use the same backend. Ah, ok. This makes a factory method somewhat less useful, because what if the canvas changes size later? Do all the paths have to be re-bound? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On Mon, 3 Mar 2014, Evan Stade wrote: I don't think you can just write a stack of inputs that accepts input for any country. The country determines: a) what fields make sense b) what fields are required c) the order of fields You could ignore (a) and settle for a crappy UI that shows all fields that make sense anywhere in the world, but you'd still be left with solving (b) and (c). (b) is an easy-to-solve problem: you don't make any of them required, and if the customer entered insufficient fields, they're not getting their package, and will have to be contacted out-of-band. I don't think the additional load that would place on customer service, the number of missing packages, etc., would be considered an easy problem or even an improvement over whatever they currently have in place. I am not convinced it'd be that big a load (users generally know what parts of their addresses are required!). But in any case, if we're talking about mom-and-pop stores with a minimal load of international orders in the first place, it's likely that the customer service load would be pretty minimal. Can you elaborate on (c)? US looks like: Recipient Organization Street address City, State ZIP Japan looks like: 〒 ZIP State City Street address Organization Recipient Ah, interesting. That is indeed a significantly larger difference than I expected. Can you elaborate on these? Where would address-line2 and address-line3 go? Where would country-name go? If the layout difference is that great, we should seriously consider documenting that also. Looking at the suggestions I listed earlier: address-line1 | address-line2 |- street-address address-line3 | address-line5 address-line6 address-line7 / locality address-line8 / region address-line9 / country-name This presumably wouldn't work sanely for Japanese addresses. Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name This _could_ work, but it seems a bit weirder than subsublocality. Or alternatively: address-line1 | address-line2 |- street-address address-line3 | region-level5 region-level4 region-level3 / locality region-level2 / region region-level1 / country-name This has the advantage of not leaving country-name dangling. address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Again, you really can't just put a stack of input fields and have it make sense anywhere. If you are presenting a UI to enter addresses, there's no way you can escape actually knowing how addresses are formatted around the world. (Well, there's requestAutocomplete.) You still need to know how to render them when printing the label, even with requestAutocomplete(). It really does seem like we should either document this order, or point to documentation on the topic. Are there Web pages out there that provide sufficient information to do this? I'm not married to the address-levelN name. [something-that-makes- sense]N is fine. The reason I'm being a bit reluctant to embrace address-level* is that it's so close to address-line*. The reason we went with proposing address-levelN is because region-levelN implies that all political regions are captured, when they aren't. There's no field for US county because county is never part of an address. So it's only for regions that actually make it onto an envelope. I don't think the implication is that strong. In fact I'd argue it's the other way around -- the implication is that this is for addresses, not generic regions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
is that this is for addresses, not generic regions. You think region-levelN more strongly implies only regions relevant to addresses than address-levelN does? Just the way that this is all about addresses is what I think implies that the fields are about addresses. Anyway, address-region-levelN, or something, is fine with me. I think the arguments you've presented so far suggest address-levelN for N=1..4, with 4=region and 3=locality, is probably the simplest thing to do. I was hoping there might be other people with opinions, to give us different perspectives on this, but it seems nobody else cares. :-( -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Hit regions and events
On Fri, 28 Feb 2014, Rik Cabanier wrote:
Reading the hit region spec [1] on event handling, I was wondering how
event bubbling is supposed to be handled. Let's say you have the
following markup:
canvas id=cnv
a id=a href=.../a
a id=b href=.../a
/canvas
and the following code:
var ctx = document.getElementById(cnv).getContext(2d);
var a = document.getElementById(a);
a.addEventListener(click, function(){...});
var b = document.getElementById(b);
// draw region for a
ctx.addHitRegion({control: a, id: a});
// draw region for b
ctx.addHitRegion({control: b, parentID: a});
Now, if there's a mouse click for control b, should the event be handled
by the handler for control a?
What do you mean by a mouse click for control b?
If you mean a click on the region for b, then isn't the algorithm for
routing mouse events on canvases unambiguous here?
Step 3 gets the region for b, step 5 gets nothing interesting, step 7 gets
the b element, step 8 sets the target to that element, and step 9
dispatches it.
Also, should event from the fallback content bubble out of the canvas
element or should it act as a barrier?
Since the HTML spec doesn't say anything about this, the DOM spec applies,
and so bubbling behaviour is as per normal for the event.
On Mon, 3 Mar 2014, Rik Cabanier wrote:
The current hit region specification doesn't state what events are routed
to the fallback content.
It states When a MouseEvent is to be fired at a canvas element, which
seems pretty unambiguous.
Probably only mouse and touch events should be intercepted and
forwarded.
Currently touch events are not routed. Should those be added?
Thinking a bit more about this feature, it's a bit weird how events are
rerouted. Does this happen in any other place in the browser?
Bindings and (in the future, there's a pending bug on this for DOM)
seamless iframes are two places that come to mind.
For instance, if the fallback is an edit control and the user
drag-selects some text on the canvas, is it expected that this text is
also selected in the edit control?
You can't validly include a text field in canvas fallback precisely
because of this kind of thing. See:
http://whatwg.org/html#best-practices
On Tue, 4 Mar 2014, Rik Cabanier wrote:
Talking to roc, event retargeting will be very complex to implement.
Why would it be complicated?
To make it simpler for authors and browser vendors, we should not intercept
the events. Instead, just keep sending them to the canvas object but add
the region's ID to it.
If the author wants to do the retargeting, he could easily do this in JS.
Having the event rerouted makes life significantly easier for authors. For
example, it means they don't have to do any hit testing or click
management for buttons, checkboxes, radio buttons, etc. It all just works.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On Tue, 4 Mar 2014, Evan Stade wrote: On Tue, Mar 4, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote: address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. Yes, this alternative works, but in my opinion is not preferable. Can you elaborate on why this would be worse than the version with synonyms? Because these words don't really mean anything. From our initial proposal: Compared to the alternative of adding another one-off such as “dependent-locality” or “sub-locality”, we feel this is a more descriptive and general way to tackle additional administrative levels without making false implications about the semantics of the value that is returned. I don't understand how sublocality makes any more implications, or has any less descriptive value, than address-level3. Can you elaborate on this? They all seem quite neutral (basically empty of meaning) to me. address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name This _could_ work, but it seems a bit weirder than subsublocality. This would re-define locality, leading to cross-version incompatibilities. How so? Are people already depending on Chinese addresses' levels 1, 2, and 3 being mapped to region, locality, and nothing respectively? The model with subsubregion does more closely match the specs' current descriptions of 'locality'. I would argue that nothing in China reliably matches the spec's current definition of locality. That is, in one address, the description for locality matches address-level1, in others, address-level2, etc. Right. In the US case, I think you're proposing that state would be region and city would be locality. Then I think it's quite likely that a developer assumes the intermediate levels like subregion would map to county, which they don't because county is an administrative region irrelevant to addresses. So I would like to keep region and locality right next to each other in all cases. But again, since these names don't really make sense everywhere, just using indexing is the least confusing IMO. I don't understand why you think authors will think they need to include subregion, but won't think they need to include address-level3. You still need to know how to render them when printing the label, even with requestAutocomplete(). It really does seem like we should either document this order, or point to documentation on the topic. Are there Web pages out there that provide sufficient information to do this? No, you don't need to know. You use the (not yet spec'd) display-address/address-blob/complete-address token that was mentioned up-thread. Why are we ok with getting a multiline text field from the user in this case but not without requestAutocomplete()? requestAutocomplete would indeed respect this token just as it respects other autocomplete tokens. You could use the multiline text field with requestAutocomplete if that's how you desired to receive the address data (and you could use it in addition to the tokenized format). This would not affect the UI of requestAutocomplete though (at least not in Chrome's case). That doesn't really answer the question. Why would we bother with all these fields if we could just use a textarea for the whole address? How does requestAutocomplete() change things? I'm not married to the address-levelN name. [something-that-makes- sense]N is fine. The reason I'm being a bit reluctant to embrace address-level* is that it's so close to address-line*. OK. To tell the truth I think address-line1 should probably be street-address-line1. Would that help clear up the confusion? Isn't it too late to change the names of the already established ones? address-line1 could be left around for a while (or eternity) for backwards-compat, while being removed from the spec, no? We're not replacing it with something new. But I'm fuzzy on the best practices here. Having synonyms is really bad. It leads to huge amounts of confusion. This is why I'm trying to avoid having synonyms for the address-level* stuff. We should definitely not add some just to introduce a slightly better name
Re: [whatwg] Hit regions and events
On Tue, 4 Mar 2014, Rik Cabanier wrote: Ok. It seems odd that the events are following the dom of the fallback elements and not of the hit regions. It's what events normally do. I guess we could make this more elaborate, but it's not clear what the use case is. Can you elaborate? It states When a MouseEvent is to be fired at a canvas element, which seems pretty unambiguous. That's not all that clear :-) Maybe it's better to state explicitly which events are routed. I don't understand. How is the current text not explicit? Are you concerned about interfaces that inherit from MouseEvent? Probably only mouse and touch events should be intercepted and forwarded. Currently touch events are not routed. Should those be added? Yes. I couldn't really see a sane way to do it (e.g. consider if two touches change at the same time, but they started on different regions on the same canvas). Do you have a proposal for how to make touch event rerouting work for canvas regions? For instance, if the fallback is an edit control and the user drag-selects some text on the canvas, is it expected that this text is also selected in the edit control? You can't validly include a text field in canvas fallback precisely because of this kind of thing. See: http://whatwg.org/html#best-practices I saw you extended the list of fallback elements to include: an element that would not be interactive content except for having the tabindex attribute specified Would that not include text fields? How would it include text fields? Can you elaborate on what you mean? I don't really follow. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hit regions and events
On Tue, 4 Mar 2014, Rik Cabanier wrote: On Tue, Mar 4, 2014 at 6:07 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 4 Mar 2014, Rik Cabanier wrote: Ok. It seems odd that the events are following the dom of the fallback elements and not of the hit regions. It's what events normally do. I guess we could make this more elaborate, but it's not clear what the use case is. Can you elaborate? The weirdness is that the pseudo hit region DOM can be different from the fallback dom. So, if b is a child of a, but the fallback element for b is not a child of the fallback element for a, you won't get the event on a if you hit b. It's not really a fallback DOM. The events don't bubble through the regions if they're not attached to a control. The parent chain is just a convenient way of managing related regions. I couldn't really see a sane way to do it (e.g. consider if two touches change at the same time, but they started on different regions on the same canvas). Do you have a proposal for how to make touch event rerouting work for canvas regions? The touch class [1] could be updated with a region string. As you move your fingers, the id would reflect what regions your fingers are on. So what would you do in the case where you start two touches on different regions, then move them at the same time to two other different regions at the same time? What would you put in the touchmove event's object? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hit regions and events
On Tue, 4 Mar 2014, Rik Cabanier wrote: So what would you do in the case where you start two touches on different regions, then move them at the same time to two other different regions at the same time? What would you put in the touchmove event's object? yes. Yes... what? I don't understand. This is not all that different from how the mouse events work with hit regions. It's different in the important sense that there's only one mouse pointer, but there can be multiple ongoing touches. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, 28 Feb 2014, Evan Stade wrote [slightly edited for correctness]: On Fri, Feb 28, 2014 at 5:47 PM, Ian Hickson i...@hixie.ch wrote [slightly edited for correctness]: My concern is that authors do something like this: input ... autocomplete=address-line1 input ... autocomplete=address-level2 input ... autocomplete=address-level3 ...and then the user enters their address: 1600 Amphitheatre Parkway Mountain View CA ...and then the user goes to another site: input ... autocomplete=address-line1 input ... autocomplete=address-line2 input ... autocomplete=address-level1 input ... autocomplete=address-level2 input ... autocomplete=address-level3 ...and the browser autofills: 1600 Amphitheatre Parkway (empty) Mountain View Mountain View CA ...or some such. So the user is tricked into entering wrong data? No, the user enters correct data, and the site uses it fine. The problem is just that the site author got the autocomplete= field names wrong. (i.e. CA for address-level3 instead of address-level1) A web author could just as easily cause the user to enter wrong data to be stored by doing: input type=text autocomplete=address-line1 placeholder=Zip code This is a concern, but far less of one, IMHO, since there's a dedicated postal-code field. How does a site know how many levels to offer? It offers as many as it knows what to do with. It probably wouldn't know what to do with n=5, or n=100, and it's highly unlikely a user agent would return a value for those levels anyway, so practically speaking, n=1 to n=3 should be sufficient for now (although n=4 seems possible in the near future). But I don't see the purpose in setting a limit in the spec. This makes me extremely uncomfortable. We're saying, we don't know how to do this, I hope you do. Why would we be less able to answer this than Web authors? It's not like Web authors are experts in postal addresses. I think we should pick the number that is actually needed, and be firm that that is the number. That's not how I would interpret it. We do know how many levels we currently support. How many? Let's put that number in the spec. We don't know how many levels we might support in the future. The number depends on political forces. Sure. We can always change the spec when we change the implementations. There's no point us allowing address-level881. It will never be useful. What should a Chinese user interacting with a US company put in as their address, if they want something shipped to China? They would put in the same address regardless of the nationality of the company, assuming the company is able to properly handle their address. Shouldn't we want everyone to be able to handle everyone's address? I think I've misunderstood your original question because I don't know how my answer indicates someone would not be able to handle someone's address. But to answer the new question, no: if I am only willing to ship to US addresses, why do I need to be able to handle a Chinese address? Well if for some reason you want to exclude non-US customers, sure. But suppose you do want to include all customers, but you're a mom-and-pop store who is just going to put what you put in the form onto the envelope, and who doesn't know the intricacies of each country's postal standards. How many fields should you list? Which inputs are visible to the user should depend on which country they're entering. This means that if a user changes the country, the inputs shuffle around and hide or show. Are we really expecting many sites to do this? I've only seen the most advanced sites do this. Nope, I wouldn't expect many sites to roll their own solution for this, which is also why most sites are completely broken at accepting international addresses. This seems like something we should fix. But requestAutocomplete offers a much easier way to support international addresses well: all the UX concerns you're raising are handled by the browser, which is an advanced piece of software. Well, I agree, but unfortunately requestAutocomplete() remains a Chrome-proprietary feature for now, so until other vendors show the slightest interest in implementing it, we shouldn't let that impact how we design the spec. The autofill fields are intended to be backwards- compatible with browsers that ignore them. Given that not everyone is going to use requestAutocomplete(), and not everyone is going to write elaborate per-country support, we're still left with the question of how many levels should people who are ok with shipping internationally include. If we're going to do this, we need to have a mapping for every locality defined in the spec. This seems like a losing proposition. Does the spec define localities? I
Re: [whatwg] Supporting more address levels in autocomplete
(even within a single country, much less across all countries). For example, region is already super generic and unhelpful. Being generic is kind of the point, since as you point out, different countries have different levels. Is there a name for these fields that you think would be less confusing to the authors? It sounds like we could have country-name, region, locality, province, but I agree that at the end of the day it's just confusing to have four words that are so vague that you can't tell what order they go in. Still, having 1,2,3,4,3,2,1 is kinda weird. Here's some dumb ideas. We could extend address-line, as follows: address-line1 | address-line2 |- street-address address-line3 | address-line5 address-line6 address-line7 / locality address-line8 / region address-line9 / country-name This leaves one unused number in the middle (4), in case we need to add to the street address side or the locality side. Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name ...or, similar, but extending region instead of locality: address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name We could make region into a multi-line field like street-address: address-line1 | address-line2 |- street-address address-line3 | locality region-line1 | region-line2 |- region region-line3 | country-name Or alternatively: address-line1 | address-line2 |- street-address address-line3 | region-level5 region-level4 region-level3 / locality region-level2 / region region-level1 / country-name Compared to those, the main proposal here doesn't seem that much better necessarily: address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name I dunno. Anyone else want to try to pick a colour for this bikeshed? Are we going to have a list in the spec giving how many levels should be given for each country? No. That is up to the site's ability to handle the data. For example, if I'm soliciting *just* US addresses, I wouldn't know what to do with address-level3, hence I won't ask for it. Ok. What do you do if you're soliciting addresses from any country? I put all the fields my database or payments backend or w/e can handle. If there's no column for address-level-4 in my database, I don't put a field for address-level-4 in my webpage. Then I hide them all and invoke requestAutocomplete. Or I write complicated JS to manipulate my markup to show the user what they expect to see based on which country they're entering info for (hide the fields that don't make sense, mark required for the ones that are necessary, etc.) requestAutocomplete() is a proprietary Chrome thing right now, so we shouldn't be recommending that people use it. (I'd love for other browsers to pick it up, since I agree that it makes things like this WAY better. But that's academic until they do.) Similarly, I think requiring complicated JS is a too-high barrier for many authors, at least if we don't give explicit advice as to what this JS should do. Hence the question, what should authors do if they're soliciting addresses from any country, if we don't tell them what this complicated JS is to do? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe scrolling attribute
On Thu, 9 Jan 2014, Mats Palmgren wrote: The current spec[1] for the scrolling attribute of [i]frame elements does not reflect what is implemented by a majority of UAs. We intend to change Firefox to implement the behavior of IE/Chrome/Safari and would like to see the spec changed to describe that behavior. There are two major problems with the current spec: 1. mapping scrolling=yes (and synonyms) to overflow:scroll 2. the mapped overflow value being a presentational hint Only Firefox implements 1 (we intend to change that[2]). None of the four UAs mentioned implements 2. The spec should instead say that scrolling=no (and synonyms) suppress scrollbars for the [i]frame viewport, and that any other value have no effect. I think what the spec used to have makes a lot more sense, but if there's a compat need, fair enough. http://html5.org/r/8517 Note that Chrome/Safari don't seem to support off and noscroll, only no. I didn't test IE. The spec supports all three, still (as does FF). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Size of non-rendered viewports
On Tue, 7 Jan 2014, Boris Zbarsky wrote:
On 1/7/14 2:24 PM, Ian Hickson wrote:
It's probably just a matter of saying, in the rendering section, that
nested browsing contexts that aren't _being_rendered_ (or that are
frames outside framesets) get a 0x0 viewport.
That doesn't seem unreasonable.
Done.
(Viewports that are being rendered seem to have an unambiguous
dimension
Actually, nothing defines this either. It should be the content box of
the iframe, assuming iframes can't get fragmented. If they can be
fragmented, I have no idea.
Fixed (well, not the fragmented case).
http://html5.org/tools/web-apps-tracker?from=8517to=8518
How about this testcase:
!DOCTYPE html
style
div { color: purple; }
/style
link rel=stylesheet href=data:text/css,%23one { color: yellow; }
media=(min-width: 300px)
link rel=stylesheet href=data:text/css,%23two { color: yellow; }
media=(max-width: 300px)
div id=one/div
div id=two/div
script
window.onload = function() {
alert(getComputedStyle(document.getElementById(one), ).color +
| +
getComputedStyle(document.getElementById(two), ).color);
}
/script
and variants on it. From my testing, in a display:none iframe:
1) Presto-based Opera treats the viewport width as 300px for purposes of the
media queries and reports a document.body.offsetWidth of 0.
2) Blink and WebKit both seems to treat the viewport width as 0 when measured
using either method.
3) Gecko doesn't allow creation of computed style objects in an iframe that's
not being rendered and reports a document.body.offsetWidth of 0.
4) IE11 seems to do what Blink/WebKit do.
Making the viewport 0x0 makes Blink, WebKit, Gecko, and IE11 consistent
here, right? Whether or not computed style objects are created is
something I'll leave up to the CSSOM spec.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On Mon, 24 Feb 2014, Jukka K. Korpela wrote: 2014-02-22 3:03, Ian Hickson wrote: (Note that a lot of people in the UK have no idea how to write their address according to current standards. For example, people often include the county, give the real town rather than the post town, put things out of order, indent each line of the address, etc.) The phenomenon is probably not limited to the UK. Few people even know the current standards (national and international). Well sure, but since we're writing a standard, if our assumption is that people don't know standards, we're not going to reach a useful conclusion. Some fine-grained control for naming different components of an address are undoubtedly useful at times. It would be even more useful to have a common, standard name for just an address. That is, whatever someone wants the sender to put in an envelope. Its internal structure does not matter, as long as it works, and as usual, it is up to the recipient to specify the address in a manner that works. Forms that require the user to split his address to small pieces may have their reasons. But if you just want to have an address to send stuff to, then all you need is a working postal address. A textarea with, say, name=postal, if used on different pages, would then let the user enter his entire address very simply, after just once typing it. Probably postal should be specified so that it relates to a postal address that is complete for delivery except the recipient name. The reason is that the name is so often asked separately On Mon, 24 Feb 2014, Evan Stade wrote: I agree with this, and plan to propose it separately from the proposal currently under discussion. It might be hard to parse a working address out of a free-form input, but the other direction is doable enough: creating a block of text suitable to printing on an envelope given tokenized values. This tackles the problem of how to format an autocompleted address for a particular country and UI language (i.e. in the user agent has to know how to do it, but the website doesn't). We can definitely add something like this. We already have a simpler version of this for street addresses. On Mon, 24 Feb 2014, Charles McCathie Nevile wrote: That depends on whether you want to force your customers to think like the Post Office, or whether you prefer to be responsive to your customers. Speaking without data, I suspect that nervousness at not being able to put *what someone thinks* is their address translates fairly readily into a certain amount of failure to proceed with a transaction. I'd love to see real data on this. I can imagine scenarios that would lead this to go both ways. On Mon, 24 Feb 2014, Dan Brickley wrote: Who is using the data? Just post offices? Or taxi drivers, pizza delivery bikers, pedestrians? The latter three are unlikely to really need much more depth at the locality level. On Mon, 24 Feb 2014, Evan Stade wrote: Regarding UK addresses, libaddressinput[1], which is used by Google for various products, currently accepts two levels of administrative region for GB: city and optional county. You need two levels, but those aren't it. :-) Counties haven't officially been used in UK addresses since the mid 90s. This would be the first open-ended field name. Do we really want to make this open-ended? What happens if a form has n=1..3, and another has n=2..4? What if one has n=1, n=2, and n=4, but not n=3? I don't know why a web author would do this Web authors do all kinds of crazy stuff. We have to be ready for it such that we never end up forced to introduce weird heuristics. but n=m doesn't require n=m-1 or n=m+1 to be present. n=2..4 would just mean the site didn't get the n=1 value. My concern is that authors do something like this: input ... autocomplete=address-line-1 input ... autocomplete=address-level-2 input ... autocomplete=address-level-3 ...and then the user enters their address: 1600 Amphitheatre Parkway Mountain View CA ...and then the user goes to another site: input ... autocomplete=address-line-1 input ... autocomplete=address-line-2 input ... autocomplete=address-level-1 input ... autocomplete=address-level-2 input ... autocomplete=address-level-3 ...and the browser autofills: 1600 Amphitheatre Parkway (empty) Mountain View Mountain View CA ...or some such. How does a site know how many levels to offer? It offers as many as it knows what to do with. It probably wouldn't know what to do with n=5, or n=100, and it's highly unlikely a user agent would return a value for those levels anyway, so practically speaking, n=1 to n=3 should be sufficient for now (although n=4 seems possible in the near future). But I don't see the purpose in setting a limit in the spec. This makes me extremely uncomfortable. We're saying, we don't know
Re: [whatwg] hit regions: limited set of elements for fallback content
On Fri, 21 Feb 2014, Steve Faulkner wrote:
But there's plenty of things which make zero sense as fallback content.
input type=color, for example, simply cannot be sanely implemented in
canvas
as implemented input type=color is a button that when activated pops up
a picker dialog.
Only on some platforms.
So the following code (as a simple example)
canvas id=myCanvas width=200 height=100
style=border:1px solid #00;
onclick=document.getElementById('button').click();
input type=color id=button
/canvas
in Firefox 30/windows when the canvas is clicked the color picker is
displayed. likewise if the the input receives focus via the keyboard and
the enter/spacebar key is pressed the picker dialog is displayed. --
And that's great if you happen to have that exact implementation. But what
about implementations where a colour palette drops down or is shown inline?
On Fri, 21 Feb 2014, Charles McCathie Nevile wrote:
I don't want to pronounce on sanity, but I don't think it has ever been
a major criterion for whether people *will* do something on the Web.
Sure. What we're talking about here is just how to guide people into what
is more sane. This is a big part of what language design, especially
opinionated language design, is all about.
And it seems pretty easy to make a colour picker in canvas. I can
imagine that anyone who wanted a specific-purpose color picker (styled
to match the site, or customising the options, or...) would do it in
canvas or SVG, and my guess is the former would be more common...
Building a colour picked in canvas would be easy. Making it accessible
using a backing logic based on radio buttons, a list box, or regular
buttons, would be easy. Making it acessible based on input type=color
would not work at all.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, 21 Feb 2014, Dan Beam wrote: While internationalizing Chrome’s implementation of requestAutocomplete(), we found that Chinese, Korean, and Thai addresses commonly ask for [at least] 3 levels of administrative region. For example, in this Chinese address: Humble Administrator’s Garden n°178 Dongbei Street, Gusu, Suzhou 215001 Jiangsu China the first-level address component is “Jiangsu” (province) as it’s the first level below country, “Suzhou” is a prefecture level city (below province), and “Gusu” is a district of Suzhou. To support this address format and arbitrarily many administrative levels, we propose adding new tokens to the autocomplete spec: address-level-n, for arbitrary n. This would be the first open-ended field name. Do we really want to make this open-ended? What happens if a form has n=1..3, and another has n=2..4? What if one has n=1, n=2, and n=4, but not n=3? How does a site know how many levels to offer? What should a Chinese user interacting with a US company put in as their address, if they want something shipped to China? The current HTML spec supports “region” and “locality”. We feel these should remain in the spec, as they are still useful for typical Western addresses. In a typical Western address, address-level-1 would align with “region” and address-level-2 would align with “locality”. So they would be synonyms? Or separate fields? Note that in the case of US addresses, in particular, the region field is often exposed as a select drop-down, not a free-form field. It's important that we be consistent as to which field maps to which list of names, in cases like this. (I don't know how common this is outside the US; I don't recall seeing it in European contexts.) Compared to the alternative of adding another one-off such as “dependent-locality” or “sub-locality”, we feel this is a more descriptive and general way to tackle additional administrative levels without making false implications about the semantics of the value that is returned. I agree that at this point, it's better to use numbers than more specific names. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, 21 Feb 2014, Kevin Marks wrote: Would putting the 2 degrees of locality as comma separated in that field make more sense? Given that this schema is the most widespread addressbook format, I'm sure someone has a dataset to discover usage (Google? Apple? Microsoft?) That's a reasonable set of questions. Anyone? Those names come from vcard - if adding a new one, consider how to model it in vcard too. Note that UK addresses can have this too - eg 3 high street, Kenton, Harrow, Middlesex, UK That's actually a bogus UK address. I'm not sure exactly which town you meant that to be in, but official UK addresses never have more than two region levels, and usually only one (the post town). The only time they have two is when the post town has two streets with the same name. (Note that a lot of people in the UK have no idea how to write their address according to current standards. For example, people often include the county, give the real town rather than the post town, put things out of order, indent each line of the address, etc.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, 21 Feb 2014, Kevin Marks wrote: On 21 Feb 2014 17:03, Ian Hickson i...@hixie.ch wrote: Those names come from vcard - if adding a new one, consider how to model it in vcard too. Note that UK addresses can have this too - eg 3 high street, Kenton, Harrow, Middlesex, UK That's actually a bogus UK address. I'm not sure exactly which town you meant that to be in, but official UK addresses never have more than two region levels, and usually only one (the post town). The only time they have two is when the post town has two streets with the same name. The real address, where I grew up, was: 2 Melbury Road, Kenton, Harrow, Middlesex, HA3 9RA Today, the address of that building is: 2 Melbury Rd Harrow HA3 9RA Damn humans, not following specs. Actually UK addresses have a huge amount of leeway, as they are routed by postcode in the main (though I did receive a postcard addressed to Kevin, Sidney, Cambridge once). The post office will deal with all kinds of stuff, sure. But Web forms only have to accept the formal address format, which in the UK only ever has a street, a locality (sometimes), a post town, and a post code. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
it
as a swimming pool flotation device. Do you try to stop them from using
your product and try to get them to purchase other pool toys, or do you
start selling your pipe insulation directly to the sporting goods
stores?
In reality? You try to stop them using your product, that's a huge
liability! There's a reason even pool noodles have a warning on the side
that says WARNING: THIS IS NOT A LIFESAVING DEVICE.
And then, if you think it's worth it, you make a device that is intended
for the purpose, and sell that.
Of course we should improve contenteditable APIs so that people who just
want basic text editing don't write their own poor replacement. But I
don't see why we shouldn't also allow people to build feature-complete
alternative text editing controls with features that might never make it
into contenteditable - like discontiguous selections, or complex
wrapping around objects.
I think you vastly underestimate the complexity of writing a text editing
control, let alone an accessible one.
People have tried to use canvas for this before, and it usually results in
them wasting months of time before realising their mistake and backing out
of it. We can save them that time by making it non-conforming.
A hit region is one that passes mouse events through to the element in
fallback content.
Instead, this would be a region that simply associates a region in the
canvas with an element in fallback content to indicate its accessible
bounds, not to propagate events.
Suppose you have some static text in your canvas. Associating the
bounding box of that text it with a p element containing an accessible
version of the same text could be very useful to screen magnifiers -
ZoomText, for example, lets you navigate to content that isn't
focusable, and it will optionally speak the text, even though it's not
intended for totally blind users.
addHitRegion() already supports this, no need for a backing DOM node even:
c.addHitRegion({
label: 'Hello World',
});
Is there any particular reason we'd want to associate the text with a
specific non-interactive element?
I think what's needed is a new event - scrollToMakeVisible. Perhaps
whenever an element gets focus, this event could fire on that element,
and the default implementation would do what's done now - but an author
could choose to preventDefault and implement their own scrolling logic.
That seems reasonable.
I think AT would like to know the region corresponding to the table
element too, not just the focusable td.
I guess for roles like grid the hierarchy is important, so it does have to
be in the fallback.
I guess col and colgroup should be exluded from this since they don't have
corresponding ARIA roles.
[...] it's not uncommon on the web for objects to do something on hover,
even if they're not focusable or clickable. For example, a static image
might have a caption that appears on hover, or a static paragraph that's
partially truncated might grow to show its full content on hover.
Allowing hit regions to map to any element would allow for the same type
of thing to happen within a canvas. An author might simply want to track
what region the mouse cursor is over, *even when that region isn't
focusable or clickable*.
Sure. Hit regions support that already. But that's got nothing to do with
fallback controls.
(Don't forget that hit regions don't _have_ to have a fallback control.
The fallback control is actually the rare case -- the common case is for
the canvas just to have text and buttons, and you can make that accessible
with addHitRegion() without any fallback canvas at all.)
Now I wonder if it wouldn't be simplest to just allow *any* fallback
content element to be the target of a hit region . It would be simpler
to spec.
Simpler to spec is the least of our concerns (literally; our concerns are
first the user, then authors, then implementors, and only then spec
writers).
So far, it seems like to support grids in canvas, we need:
- enable table-related elements (table, td, tfoot, etc) to be hit region
controls. (exclude col and colgroup)
- fire an event on an element when the user agent (possibly because of a
request from the AT, but not necessarily) wants to scroll to an
element; default action is to actually scroll.
- when this event is fired on a canvas, include the region information.
...and to support list boxes, we need:
- enable select multiple elements to be hit region controls.
- enable select size=N eements where N1 to be hit region controls.
- enable option to be hit region controls.
- optionally, if implementors are on board:
- make select size=1 in canvas act like size=N where N1.
- enable select size=1 elements to be hit region controls.
Are there any other use cases we should address?
What's your take on the select thing; should we have a special case in
browsers for size=1, or should we require size1?
--
Ian
Re: [whatwg] hit regions: limited set of elements for fallback content
On Thu, 20 Feb 2014, Dominic Mazzoni wrote: On Thu, Feb 20, 2014 at 10:37 AM, Ian Hickson i...@hixie.ch wrote: So far, it seems like to support grids in canvas, we need: - enable table-related elements (table, td, tfoot, etc) to be hit region controls. (exclude col and colgroup) Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24750 - fire an event on an element when the user agent (possibly because of a request from the AT, but not necessarily) wants to scroll to an element; default action is to actually scroll. - when this event is fired on a canvas, include the region information. Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24748 ...and to support list boxes, we need: - enable select multiple elements to be hit region controls. - enable select size=N eements where N1 to be hit region controls. - enable option to be hit region controls. - optionally, if implementors are on board: - make select size=1 in canvas act like size=N where N1. - enable select size=1 elements to be hit region controls. Filed this as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24749 What's your take on the select thing; should we have a special case in browsers for size=1, or should we require size1? I can't think of a way to make size=1 work, so requiring size1 may be the only option. It seems ugly, though. The way we could make it work would be to change the logic in the select so that when it's in a canvas, it's a list box and not a drop-down. But that might be more confusing than requiring that people set size=2? I guess I'll just punt on this for now and we'll see whether authors get confused or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Mon, Feb 17, 2014 at 11:02 PM, Ian Hickson i...@hixie.ch wrote: What about select? What about it? I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? Right now, this is intentionally not possible, since it seems that if you want a select, you really should be using a select, not a canvas. But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. But see above for the case of select specifically; it's not that simple in practice. It seems to me that I could make each visible option a hit region - why couldn't we make this work? We can make anything work if we want to; the question is what do we need to make work. Simple grids are supported the same way that simple menuitems are supported; again, though, once you get to elaborate grids with cells that can be marked invalid, marked as having popups, etc, you really shouldn't be using canvas, so those aren't supported. So you don't think people are going to implement something like a spreadsheet using canvas? No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: http://whatwg.org/html#best-practices ...plus a whole new set of problems relating to how to expose navigating a grid (right now there's no API for determining where the AT focus on a table is, so you couldn't just map a fallback table to a canvas rendering, it wouldn't work). A spreadsheet is one possible use-case, though I agree it's complicated. The spreadsheet use case is already handled by table. If the problem is that we need something more performant than DOM+CSS, then we should provide something for that. Providing a pixel pushing interface is no real solution (see the #best-practices link above for a long list of reasons why not). This is the same reason that a spreadsheet is not a good use case for introducing a mechanism to do underlining: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0068.html How about a crossword puzzle game as a more realistic example, where the author wants to draw the whole puzzle in a canvas, not put a canvas inside each cell? Why would you use a canvas for a cross-word puzzle, rather than a table? Games like tic-tac-toe, chess, or reversi would also be reasonable use-cases to consider for this. For 2D versions, why wouldn't you use a table? I don't understand what the cavnas is bringing to the table here. For 3D versions, the addHitRegion() API doesn't apply, so that seems like a separate issue. But ok, let's look at a 2D grid like chess or a cross-word. What would you actually need to make that work? canvas table onkeypress=handleKeyInput tr td tabindex=0 I td tabindex=0 N tr td tabindex=0 F td class=black aria-readonly=false /table /canvas What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? Where is the keyboard focus while the AT focus is on the black cell? Imagine the crossword is so large that it doesn't fit on the canvas, and so the script scrolls the canvas around as the user tabs from cell to cell. Now what happens when the user moves AT focus to a black cell that isn't currently being rendered? Do we have some way to find out that a region is being AT focused? What happens if the keyboard focus and the AT focus get so far from each other that we can't render both at the same time? Which should we be rendering? How do native apps handle these cases? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Rik Cabanier wrote: Why would you use a canvas for a cross-word puzzle, rather than a table? Because it is easier to code a nice interface. See this Google doodle: http://www.google.com/logos/2013/crossword/crossword13.html It's fully keyboard navigable but inaccessible since the grid is drawn with canvas. I don't see anything there that really needs canvas. In fact, it seems like it would be substantially easier to implement without canvas. But it is a good example of why we need to answer the questions in my last e-mail before we can properly support it: What happens if the user navigates the table with their AT and moves the AT focus to the fourth cell? It's not focusable, but do we still need to be telling the AT where the cell is? What happens if we haven't told it where the cell is? Where is the keyboard focus while the AT focus is on the black cell? Imagine the crossword is so large that it doesn't fit on the canvas, and so the script scrolls the canvas around as the user tabs from cell to cell. Now what happens when the user moves AT focus to a black cell that isn't currently being rendered? Do we have some way to find out that a region is being AT focused? What happens if the keyboard focus and the AT focus get so far from each other that we can't render both at the same time? Which should we be rendering? How do native apps handle these cases? This example actually adds more questions: How do we handle the multiple focus case? (There's focus in the crossword and in the clue list at the same time.) Do we expose the way each cell can be focused in two different directions? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 10:51 AM, Ian Hickson i...@hixie.ch wrote: I'm curious if it's possible to implement an accessible list box or other select control in a canvas. Wouldn't it be possible to make it accessible if the canvas lets you focus the list box by clicking on its hit region, and then change the selection using the arrow keys? What's the concrete use case? How can I get more concrete than there's a list box inside a canvas? Well for example, is the use case one of the controls on Bugzilla's advanced search page?: https://www.w3.org/Bugs/Public/query.cgi?format=advanced If so, I feel comfortable saying that we don't need to make canvas support that, since that use case is already handled very well by the select element. Whether or not we think it's a good idea, people are building entire UIs using canvas. Sometimes it's in order to achieve pixel-perfect rendering accuracy across browsers and platforms, sometimes it's for speed, sometimes it's for visual effects that aren't possible in HTML, sometimes it's because they're building a cross-platform UI. Just because people do it doesn't mean we need to design our APIs around it, or otherwise endorse it. For example, people use table elements for layout purposes, but this is expressively against the table conformance requirements. People use blockquote for indenting, but instead of providing a blockquote indent-depth attribute, we improve CSS to support indenting. And so on. Asking web developers not to build UIs in canvas is like asking Windows, Mac, iOS, or Android developers to not build custom controls. It's not going to happen. Sure, but that misses the point a little. We are developing technologies for custom controls -- Web components. To support a select drop-down, you need much more than just a canvas: you need a way to show a popup window, you need a way to draw shadows over underlying content, etc. So this is why I ask for the precise use cases. We can only evaluate if the technologies are actually addressing needs by going through and seeing how they do with precise use cases. If the use cases are very vague, we can at best guess, and we might guess poorly. What if I do want a select, but I just want a canvas to render it visually? Are Web Components and CSS unable to get the effects you need? Maybe we should be improving those rather than canvas. It's hard to tell without knowing precisely what you want to do. But if there's a valid reason to have a list box or other select control in a canvas, then we should examine that reason and see what precisely is needed to make it possible. (It's probably a lot more than just exposing a select, since you'd need some way to map the open select popup's focus to canvas, and there's no API to do that currently.) Agreed about the open select, which is why I was thinking about the subset of cases that could work - like a select that doesn't open but just lets you change its value with up/down buttons or with arrow keys. Well we wouldn't want to expose a non-multiple size=1 select in the canvas fallback for that kind of thing, because such a select allows you to do things like open the popup, and then we'd be in a horrible situation for AT users (and indeed keyboard users), where you could be navigating something you can't see, the AT would be describing things that don't match the screen, and the script would have no idea what was going on. If what you wanted was just a series of menu items to cycle through, you can do that with addHitRegion() pretty easily. That's just the menu item case I described earlier. What about a list box using ARIA instead? canvas div role=listbox div role=option tabindex=0First option/div div role=option tabindex=-1Second option/div div role=option tabindex=-1Third option/div /div /canvas Why would you use divs in the canvas fallback? Just use the real control, like a select. Because when I do it this way, I can make each (visible) option a hit region, rather than the entire control being one hit region. Why wouldn't you just use select and option? If we want to support list boxes in canvases (which is unclear to me; I don't understand what the use case is), I don't think it would make sense to support it with divs when we have a perfectly good control for it already. No, canvas would be a disaster for implementing a spreadsheet. You'd have all of the problems already described for text controls: Yes, but people are implementing text controls in canvas too. We can't ignore that. We shouldn't ignore it; we should provide better solutions that make it so they don't feel the need to do it. If a region has a car theft problem, you don't solve it by giving all the thieves the car keys. You solve it by improving the economy so that thieves have better
Re: [whatwg] hit regions: limited set of elements for fallback content
On Tue, 18 Feb 2014, Dominic Mazzoni wrote: On Tue, Feb 18, 2014 at 11:39 AM, Ian Hickson i...@hixie.ch wrote: This example actually adds more questions: How do we handle the multiple focus case? (There's focus in the crossword and in the clue list at the same time.) I don't think multiple things are focused at once. Rather, certain composite controls have a notion of which cell is active, that becomes the focused cell when you focus it. If you have a select multiple control on your page, you can tell which items are selected even when it isn't focused, and I think this is the same thing. Yeah, it's not clear exactly what is focused, per se. It could be the cell, or it could be the clue. I'm not sure how to tell. Tab jumps through the clues, the arrows keys jump through the cells. Clicking either has the same/equivalent effect. Both need to be called out when you focus either. Do we expose the way each cell can be focused in two different directions? I don't see how that would translate into an accessibility API, even in a native app. I think the author would have to semantically convey that via some other means. Right, but, what other means? That's what I'm trying to work out. How would we actually solve this specific use case? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=number for year input
On Tue, 18 Feb 2014, Jonathan Watt wrote: When implementing input type=number for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as 1,234. This is causing a problem for at least media wiki, because they use input type=number for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIXaction=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use input type=number for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. My recommendation would be to just use comma separation for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. type=number does seem appropriate for years, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=number for year input
On Tue, 18 Feb 2014, Jonathan Watt wrote: My recommendation would be to just use comma separation It would be the appropriate separator(s) for the locale in use, not necessarily the comma, but I'm guessing that's what you meant. Sure. for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. Personally I think it's a bit more than a bit weird to have Year: 2,014. It seems pretty ugly to me, and four digit years are going to be the common case. type=number does seem appropriate for years, though. I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types... This has come up a few times, but so far the use cases have not been compelling enough. This is probably the most compelling use case, but even here, I don't know that it's that compelling. I would be interested in hearing more about the locales where not using separators even for four digits is bad/suboptimal. If it wasn't for those, I would say that just not using separators for four-digit numbers would be an easy and effective solution. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, 17 Feb 2014, Rik Cabanier wrote: The current spec for hit regions restricts what elements can be used as fallback content [1]: [...] Why is there this limitation? It supports the content model restrictions, which are there to avoid authors making mistakes that harm accessibility (amongst other things). Reasons for content model restrictions are discussed in more detail in the introduction to the spec: http://whatwg.org/html#restrictions-on-content-models-and-on-attribute-values If there are specific use cases that can't be done given the current restrictions, please let me know; we can definitely consider relaxing some of the restrictions. (It's very hard to tighten restrictions, but comparatively easy to relax them, which is why we start them on the strict side rather than on the relaxed side.) So far, all the use cases that people have brought up for things that can't be done within the current restrictions also happen to be things that canvas is actually really bad at doing at all. There's another non-normative section that goes into more detail about these kinds of things: http://whatwg.org/html#best-practices -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, 17 Feb 2014, Rik Cabanier wrote: Were those use cases posted to this list? I'm sure some were. Your typical use case would be something like a graph, a game menu, a fractal explorer, and so on. So, you wouldn't want the same limitations as for regular HTML elements? Not sure what you mean. The rules for addHitRegion() match the regular canvas content model. http://www.whatwg.org/specs/web-apps/current-work/#wai-aria This seems orthogonal to the issue of addHitRegion()... I'm not sure I follow the relevance here. The canvas fallback content could be what is exposed to the user so it might be painful for the author to match it up with hit regions. Not sure what you mean here. Can you elaborate? Maybe an example would help. I agree that relaxing it to any element could allow non-sense. Is there a clear definition of what is disallowed or allowed in HTML? I couldn't find it in the spec. Allowed or disallowed in what sense? If you mean the content models, the specification has elaborate text describing the rules; you can find the introduction to content models here: http://whatwg.org/html#content-models -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: limited set of elements for fallback content
On Mon, 17 Feb 2014, Dominic Mazzoni wrote: On Mon, Feb 17, 2014 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: If there are specific use cases that can't be done given the current restrictions, please let me know; What about select? What about it? What about an element with a tabindex and an ARIA role that corresponds to a control? Can you elaborate? Note that there are a few ARIA roles for interactive controls that don't have matching HTML counterparts, like gridcell, menuitem, or spinbutton. Sure. addHitRegion() supports roles like menuitem this in two ways: If you're doing something like a straight-forward menu item, you can just add the text and the role directly. If you're doing something more elaborate (e.g. a menu with disabled items), you can add appropriate elements (e.g. button) representing the menu into the canvas fallback content, and use ARIA roles and properties to override button's defaults. Once you get to more elaborate compound controls like spin buttons, you really shouldn't be using canvas in the first place, and so those aren't supported (spinbutton in particular would be impossible to correctly support in a canvas, since it's a compound control with multiple subregions, all corresponding to a single DOM node on the ARIA side). Simple grids are supported the same way that simple menuitems are supported; again, though, once you get to elaborate grids with cells that can be marked invalid, marked as having popups, etc, you really shouldn't be using canvas, so those aren't supported. That's what table is for. If you want a table with graphics inside, the way to do that is to have a table with each td containing a canvas, not a single canvas. This is relatively important because users really don't want authors reimplementing table navigation themselves -- indeed I'm not even sure it's technically possible for an author to track the AT focus as the user navigates a table using AT commands, so it would be incredibly difficult for an author to do a good reimplementation of a grid on canvas. If there are specific use cases for why you'd want to recreate a table using canvas, please do describe it. If we need to support this, then we should make sure we do a good job (as noted, the current APIs aren't sufficient, even if we just make addHitRegion() support pointing to td elements in the canvas fallback content). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: moving an element out of the shadow tree
On Fri, 7 Feb 2014, Rik Cabanier wrote: Another question: it is currently valid to pass in a control that is not part of the canvas shadow tree. Doing this will ignore the control. Shouldn't this be invalid and throw an error? APIs don't really have a concept of valid or invalid. It doesn't throw, because the control might have just been created and the author might have painted it before adding it to the canvas. It'll work once the control is a descendant of the canvas. You can use this to temporarily stop events being propagated, while keeping the region around. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Wed, 18 Dec 2013, Ami Fischman wrote: On Wed, Dec 18, 2013 at 8:38 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 17 Dec 2013, Ami Fischman wrote: Recently https://www.w3.org/Bugs/Public/show_bug.cgi?id=23263 Navigator acquired the ability to enumerate media output devices (in addition to input devices): http://dev.w3.org/2011/webrtc/editor/getusermedia.html#enumerating-devices What's the privacy story for this API? I don't follow public-media-capture but the spec above says: The method must only return information that the script is authorized to access (TODO expand authorized). That should probably be resolved before we start integrating other specs with the API, since without a solid privacy story, the API might change radically. In fact, looking at the spec again today, I can't find anything about enumerating anything. (Indeed, the word enumerating doesn't appear in that spec.) Am I missing something? There doesn't seem to be a table of contents either... Anyone know the status of that spec? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Guessing the fallback encoding from the top-level domain name before trying to guess from the browser localization
On Thu, 19 Dec 2013, Henri Sivonen wrote: Considering that the encoding of the content browsed is not really a function of the UI localization of the browser, though the two are often correlated, I have developed a patch for Firefox to make the guess based on the top-level domain name of the URL of the document when possible. Before deciding whether to land that patch, I'd like to get feedback from the broader Web standards community. Does this seem like a good idea? Good idea if the mapping details are tweaked? Bad idea? (Why?) Seems like a reasonable idea to me. The correlation should be at least as high, as far as I can tell. But that's just a guess. Data would be good, for example instrumenting an existing locale-based browser to see how often the guess from the locale disagrees with the guess from the TLD, and checking how often the guess from the locale is wrong (via looking at people overriding the encoding manually). Or maybe a 50%/50% experiment with that as the first 50% and the default coming from the TLD instead of the UI locale in the second 50%, with the corresponding instrumentation, to see how the results compare. Have you tried deploying this? What have you learnt so far? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Fri, 7 Feb 2014, Ami Fischman wrote: The link you're looking at is currently being used to focus the WG's attention on the Constrainable business, which is why everything else has disappeared. This is temporary :) See http://lists.w3.org/Archives/Public/public-webrtc/2014Feb/.html for the haps, and the previous editor's draft ( http://dev.w3.org/2011/webrtc/editor/archives/20131225/getusermedia.html) for the pieces of the spec discussed in this thread here. Ah. Well, I can't reference a spec that's that unstable. :-) Can you let us know when there's a URL that will permanently hold the latest (including day-to-day updates) spec? Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [Canvas] Behavior on non-invertable CTM
On Thu, 6 Feb 2014, Justin Novosad wrote: I am looking into correcting Chrome's behavior to make it spec-compliant in this case. There is one specific primitive that is proving problematic: arcTo The problem is that the algorithm needs to bring the last point in the subpath into the arc's local coordinate space, which requires inverting the CTM. Current text: If the point (x0, y0) is equal to the point (x1, y1), or if the point (x1, y1) is equal to the point (x2, y2), or if both radiusX and radiusY are zero, then the method must add the point (x1, y1) to the subpath, and connect that point to the previous point (x0, y0) by a straight line. I don't understand why this needs the last point in the subpath to be converted to the arc's local coordinate space, rather than the other way around. Can you elaborate? why can't you convert all the points to the current coordinate space before doing the comparisons? (I'm probably missing something critical here.) As far as I can tell, quadraticCurveTo and bezierCurveTo do not have this problem because the curves can be computed by first transforming all points to global coordinate space, to compute the curves in global space. Why is this not the case for arcs? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: moving an element out of the shadow tree
On Mon, 3 Feb 2014, Rik Cabanier wrote: The spec is currently silent what should happen when an element that is associated with a hit region, is moved to another location in the document, another document or deleted. This should result in removal of the hit region. Maybe this is defined in the HTML spec? It results in the region no longer having a backing control (see the definition of the control represented by a region), but why would it remove the region? The region might be there for other reasons, e.g. it might have a cursor or ID specified, or the author might be using it to play a sound when the user tries to click on the space where the control used to be drawn, to indicate to the user that the control is gone. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Document.title for SVG documents
On Tue, 4 Feb 2014, Anne van Kesteren wrote: Given that this does not define a html:title in html:head it's non-conforming anyway so that seems fine. (I'm assuming we're using HTML parsing rules of today.) The spec actually allows title to be ommitted in a number of cases, e.g. srcdoc documents, and we may extend this in the future (e.g. documents intended only for use in iframes). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] hit regions: moving an element out of the shadow tree
On Tue, 4 Feb 2014, Rik Cabanier wrote:
On Tue, Feb 4, 2014 at 9:13 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 3 Feb 2014, Rik Cabanier wrote:
The spec is currently silent what should happen when an element that
is associated with a hit region, is moved to another location in the
document, another document or deleted.
This should result in removal of the hit region. Maybe this is
defined in the HTML spec?
It results in the region no longer having a backing control (see the
definition of the control represented by a region), but why would it
remove the region? The region might be there for other reasons, e.g.
it might have a cursor or ID specified, or the author might be using
it to play a sound when the user tries to click on the space where the
control used to be drawn, to indicate to the user that the control is
gone.
Ok, link:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-control-represented-by-a-region
It's a bit weird that you can do ctx.addHitRegion({}); :-)
Or even just c.addHitRegion(). An author might want to do that to
introduce a dead zone in a canvas, where the cursor reverts to the
canvas default cursor, there's no AT implications, and the hit testing in
mouse events doesn't give a region ID any more. This is similar to area
elements with no href=.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in script tag
On Sat, 14 Dec 2013, Some Developer wrote: Currently most people store their JavaScript code on a CDN of some sort. This often involves uploading their JavaScript files to a server hosted and run by a third party which means the control and security of the server is out of the hands of the website owner. If the CDN is hacked or a rogue employee decides to edit your JavaScript you might end up serving malicious JavaScript to your users without even knowing it. In order to overcome this problem I propose that a new attribute is added to the script tag which allows the website owner to specify a SHA512 hash of the JavaScript file ahead of time. If when the file is downloaded from the CDN by the browser it does not match the SHA512 hash in the HTML the browser should discard the JavaScript file and display a warning to the user that the file has been modified and that it should be considered as malicious. How common is this problem? Are there really sufficiently large numbers of people who use trusted computers to serve one part of their application, but use comparatively untrusted computers to serve subresources, to warrant such a feature? Presumably, anyone using shared hosting or a colo with a private server would be no more able to trust their primary server as their CDN. (Or equivalently, they'd be no less able to trust their CDN than their primary server.) Does anyone do this manually today? It would be relatively straight- forward to use CORS-enabled XHR to obtain the remote script, and then check the hash manually using script obtained from the primary server, and only eval the script if it matched. If nobody is doing this today, this probably indicates it's not a high priority for the platform. On the other hand, if people _are_ doing this, then that's a good indication that we should add it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus
On Sat, 1 Feb 2014, Cameron McCormack wrote: Document.activeElement is currently defined to return the body element if there is not element with focus, or null if there's no body element. I think it needs to return the root element when the document isn't an HTML document (like an SVG document). I'm actually about to completely revamp how focus is defined, so that it actually matches reality way better (e.g. right now the spec completely misses that it's the viewport that's focused when nothing is focused, and fails to even allow scroll regions to be focused, etc), and so that it properly supports dialogs as a separate kind of focusable object. I have a detailed proposal here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475#c16 I've noted your proposal above in comment 18. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus
On Mon, 3 Feb 2014, Anne van Kesteren wrote: On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack c...@mcc.id.au wrote: When the document isn't an HTML document and when there is no element with focus. Browsers agree on returning null in an HTML document when there is no element with focus, no body element, but still a document element. That case is obscure, though (I mean, it can only happen if you literally replace the body or frameset element with something else, like a div... and while I acknowledge that the Web is a wild, wild place, I doubt there are many pages that actually do that and, on top of that, depend on activeElement returning null). It seems simpler to just try to use the body element (as defined in the HTML spec, it's not a body necessarily), and if that fails, use the root if there is one or null otherwise. On Mon, 3 Feb 2014, Boris Zbarsky wrote: What Gecko does is that if the document is an HTMLDocument (so is text/html or application/xhtml+xml) and hence has a .body property we use that. Otherwise we use .documentElement. Of course the spec has no concept of HTMLDocument and has a .body on all documents... Yeah, that would hurt the ability to use HTML from other namespaces (since the HTML helper stuff on the Document would be missing). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Document.title for SVG documents
On Sat, 1 Feb 2014, Cameron McCormack wrote: Currently, HTML defines Document.title on SVG documents to defer to whatever the SVG specification defines for SVGDocument.title. The SVGDocument interface has gone away, so this will need to be updated. From some basic testing, it looks like SVG needs the same behaviour as HTML -- first title element in the document, plus the white space collapsing behaviour. Do you want to just handle that all in HTML? I'm not sure there's much value to duplicating either the searching for the title element or the white space collapsing behaviour in SVG itself. I'm all for handling it in one place. What precisely do you want the behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- the first svg:title element may come after the first html:title element, and vice versa. Also consider when one or the other is primary but the relevant element is absent.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comments on dialog
On Mon, 3 Feb 2014, Brian Blakely wrote: On Fri, Jan 31, 2014 at 7:31 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 18 Dec 2013, Brian Blakely wrote: This is what the shadow DOM would look like for modal dialogs: ::modal - ::backdrop - dialog ::modal is dialog's ancestor, and is available when showModal is called. This allows authors to set CSS overflow to whichever value suits their use-case, and for user agents to establish overflow: auto as the default, making the dialog inherently pannable when it exceeds the viewport. That seem somewhat novel, from the CSS perspective. I'll have to defer to implementors as to how feasible something like that is. [...] ::modal is essentially a named alias for ::outside ( http://www.w3.org/TR/css3-content/#wrapping), which, sadly, has not been implemented anywhere and hasn't seen public movement in quite a long while. Yeah. ::outside is pretty novel also, from a CSS perspective. That might well be why it hasn't gone anywhere since I originally specced it in early 2002/2003. I think it'd be great for it to be implemented, but we're more likely to get there by pushing ::outside than trying to push a special case version of it, I think. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] onclose events for MessagePort
On Mon, 3 Feb 2014, Jonas Sicking wrote: I agree that being able to prevent an object from getting GCed isn't great, however any solution in this space is going to require the UA to retain a bit more memory. The reason that we need to retain the MessagePort object in the solutions discussed so far is that we've tried to fire the event on the MessagePort object itself. If we instead fired an event on the global indicating the other side has gone away, then a MessagePort doesn't need to be retained. However such a solution requires a different way to identify which communication channel was severed. We could allow naming ports and then the name of the port would be included in the lost connection to an other side. Of course, that requires keeping that name in memory which is arguably as leaky. Or we could come up with numeric port identifiers, in which case less memory is leaked. I think this would just result in authors keeping track of the ports in an index, which would prevent them from being GC'ed, which defeats the point. The bfcache issue is solvable as discussed. [...] As soon as any of them can't deal with bfcache the page won't be bfcached. I don't think solvable is the same as design an API that basically guarantees that within a decade most of the Web won't be bfcached. I'm happy to experiment. In the meantime I would ask that MessagePort.onerror is removed as I don't think any browser vendor has expressed a desire to implement. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inputmode feedback
On Mon, 3 Feb 2014, Michael[tm] Smith wrote: Ian Hickson i...@hixie.ch, 2014-01-22 00:54 +: The idea of the inputmode= attribute is that it gives the mode that is most likely to be needed by the user when providing input. There's various modes that seem to make sense: - inserting raw latin-script characters, like passwords, product codes - inserting human-readable latin-script short-form text, like search queries - inserting human-readable latin-script human names - inserting human-readable latin-script long-form text, like blog posts - inserting numeric data, like credit card numbers - inserting text in other scripts, of which I know nothing - inserting human-readable latin-script text within long-form text in other scripts You don't use the same kind of keyboard for inserting raw latin-script characters as for inserting Japanese long-form prose, so it makes sense to me that they'd use different input modes. Why is this wrong? I personally think it's not wrong. Well, mostly not wrong, at least (see below for what I think is one specific, fixable problem.) But I believe one objection that others have made to the current set of modes is that for Latin input it provides values that conflate typing-aids hints with the script hint, while for Japanese input, it does not. Well, nobody has suggested that there are any typing aid hints applicable to Japanese input yet. The current list for Japanese (and all non-Latin- script languages) are just the list of input modes people told me were needed (since nobody has asked for anything for anything but Japanese and Latin-script languages, there's nothing for those). That means there's at least one possibly-useful mode that inputmode currently does make expressible: a name mode for kana input (to correspond to the latin-name mode). Added. What I mean is, what value would an author choose if they wanted to indicate a mode for inserting human-readable kana-input human names? As of now, kana-name. Asking that question makes me realize that we probably don't actually want a -name mode for the contact-list case anyway -- because a Japanese user is likely to have a contact list that contains names both in Kanji and in Latin characters. So if we really want to provide text prediction from the user's contact list, I think we'd probably want to just add an script-less inputmode=contact value for that. If there was going to be a keyboard that consisted primarily of a contact list, I'd agree. But the keyboard will be a keyboard, and it'll autocomplete from a contact list. And thus that keyboard needs a default mode to be in. If all my friends have Latin-script names, it is inconvenient if the keyboard starts with a Russian keyboard. I presume, based on what you suggested above, that a Japanese user would find it more helpful if their keyboard started in a mode for kana or romaji input, typically hiragana input. Also, there are things other than human names for which namecase (aka titlecase) is useful: For example, a field where the user is expected to type in a book title or movie title. For those kinds of fields, you clearly wouldn't want text prediction from the user's contact list turned on also. Instead you'd just want it to be inputmode=titlecase. If users actually want auto-title-casing, then yes, we could introduce a latin-title-case mode, or something like that. Do they? I haven't heard of a request for this so far. Anyway, I think the root problem might be that we have inputmode=latin-name to begin with. I don't understand why it's a problem. So I'd suggest either dropping it entirely, or replacing it with the two new values inputmode=titlecase and inputmode=contact. That wouldn't give the UA the information the UA needs to pick the right keyboard. And as far as using inputmode for specifying typing aids instead of just script, I don't what other kinds of typing aids (other than the contact case) would be relevant for Japanese input. The main typing aids the spec mentions are autocapitalization, autocorrect, and text prediction. Among those, capitalization isn't relevant for Japanese input at all. And as far as autocorrect, in my experience at least, autocorrect isn't a feature that's commonly used anywhere with IMEs for Japanese input, so it's not relevant. And as far as text prediction, in Japanese IMEs text prediction is always turned on anyway, and I can't think of cases where a user would really care to have it turned off (or be bothered by having it on). Right, each script has different needs. That's why these are not orthogonal concerns; they're input modalities. I don't know anything about what input modalities are needed outside of Latin script keyboards, so I rely on people reporting what is missing so that I can add it. Come to think of it, in soft keyboards
Re: [whatwg] Proposal: Locale Preferences API
On Thu, 12 Dec 2013, Jungshik Shin (신정식, 申政湜) wrote: 2013/11/27 Boris Zbarsky bzbar...@mit.edu On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote: That is, I suggest that 'navigator.language' always be the UI language of a web browser. That's an unacceptable privacy leak from Mozilla's point of view. See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we explicitly switched from that to basing navigator.language on the Accept header. Well, the vast majority of users would never touch A-L list. So, the top entry in the A-L list would remain the default value, which is usually the UI language. So, I don't know how much your change helps privacy if revealing the UI language is indeed a valid privacy concern. On Fri, 13 Dec 2013, Boris Zbarsky wrote: The point is, the Accept-Languages header already reveals whatever it reveals, so there is no additional privacy leak from navigator.language if you just mirror what the header. And for people who _do_ change the A-L list, they get it picked up in both places automatically. It does seem reasonable that the three APIs (the header and the two IDL attributes, one giving one value and the other a list) would expose the same information, or at least subsets thereof (for the single value one). Jungshik, is there any particular reason for _not_ doing this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inverse property mechanism for Microdata?
On Fri, 31 Jan 2014, Dan Brickley wrote: We'd (schema.org 'we') like to make a public proposal to update Microdata with a syntax for expressing inverse properties/relationships. [...] Here's an example with 'containedIn'. The idea is that we want to express that the LocalBusiness (i.e. Place) Entity B is 'containedIn' Entity A. The example I show here expresses the reverse, incorrectly. So we're looking for a change to the markup that would turn this example into one that said The LocalBusiness Entity B is containedIn the LocalBusiness Entity A: div itemscope itemtype=http://schema.org/LocalBusiness; h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemprop=containedIn itemscope itemtype=http://schema.org/LocalBusiness; h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div This is actually possible today: div itemscope itemtype=http://schema.org/LocalBusiness; id=a itemprop=containedIn h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemscope itemref=a itemtype=http://schema.org/LocalBusiness; h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div The trick here is to turn the inner item into the top-level microdata item, and use itemref= to have that inner item point to the outer item. (This works great unless you want two items to refer to the same third item using different properties, but that's something microdata can't do in general, since it's based on a tree structure, not a graph structure. To address that particular problem, you need a vocabulary that defines how itemid= works; at that point, you can just have the same underlying item represented as multiple microdata items in the document by having all the items share the same ID. But how exactly that is to be interpreted is something the vocabulary has to define.) One response is that the markup could be reorganized. That's basically what the above does, but without moving the elements around in the DOM. (itemref= is basically all about making the microdata model work around constraints coming from the author's preferred DOM.) Another reasonable response to this is 'well, perhaps you should have a property (instead or in addition) called geospatiallyContains, or containerOf or contains, or rev_containedIn for this usage scenario'? That is another option, similar to the parenthetical itemid= note above -- you could just have the vocabulary define that for every property whose value is an item, the item type that that property can point to has another property with the same name plus a fixed suffix, like -inv, that inverses the relationship. That would make the above look like: div itemscope itemtype=http://schema.org/LocalBusiness; h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemprop=containedIn-inv itemscope itemtype=http://schema.org/LocalBusiness; h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div We have tried this and in a few cases we have included pairs of inverse properties in schema.org, e.g. we have alumni and an inverse, alumniOf. In designing schemas we have found it consistently hard to get even a single natural/intuitive name for each property, and finding a good name for the inverse of each makes the task even heavier. Appending Of (or other fixed suffix) doesn't always work well; e.g. containedIn / containedInOf barely makes sense. Yeah, you'd have to just pick a suffix like -inv or a prefix like rev- or something that doesn't attempt to give a good English meaning. The advantage of doing that is that you could then define this for the vocabulary generically, and process it generically, rather than having to actually define and support each individual property. HTH, -- Ian Hickson U+1047E
Re: [whatwg] Comments on dialog
On Wed, 18 Dec 2013, Brian Blakely wrote: On Wed, Dec 18, 2013 at 2:13 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 18 Dec 2013, Brian Blakely wrote: On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson i...@hixie.ch wrote: I've added a rule to the spec that says that viewports have to be pannable so you can see all of a dialog, but I don't know how feasible that really is. I could see implementations using shadow divs to satisfy this It might be beneficial to even codify kind of element as ::modal, representing a modal layer acting as an ancestor for both the ::backdrop and dialog. Not really sure how this would work. Can you elaborate? This is what the shadow DOM would look like for modal dialogs: ::modal - ::backdrop - dialog ::modal is dialog's ancestor, and is available when showModal is called. This allows authors to set CSS overflow to whichever value suits their use-case, and for user agents to establish overflow: auto as the default, making the dialog inherently pannable when it exceeds the viewport. That seem somewhat novel, from the CSS perspective. I'll have to defer to implementors as to how feasible something like that is. So far, the feedback doesn't seem positive: On Thu, 19 Dec 2013, Elliott Sprehn wrote: We can't implement that inside Blink. It requires dialog to have two parents, the real one in the DOM and ::modal. The only way I can see this working is if we special case the Shadow DOM projection logic for dialog so that it is always projected into ::modal, but we don't want any special cases in projection. I've not put this ::modal model in the spec. On Wed, 18 Dec 2013, Brian Blakely wrote (continuing from above): 3. When the modal dialog's height changes, either due to CSS or content changes, the vertical position of the dialog should change (unless the height exceeds the viewport height). That's an interesting idea, but I'm not convinced it's the right answer. Having the dialog move up and down when stuff is added at the bottom would be quite weird. You can always implement this manually from script. To go back to hacky and rather difficult-to-maintain JS techniques for something so simple seems antithetical to the intention of dialog to me. Modern modal implementations don't require that. My point isn't that we shouldn't offer the feature because it is already possible. My point is that this feature is actively bad. I'm saying I don't think it's good UI for the dialog position to change when it increases in height. It looks like Blink's implementation will recenter the modal when show/showModal are called. That's per spec, yes. The suggestion above was regarding when the dialog changes size while it's already visible, I believe. You're correct. I was pointing out that there is already a means of recentering, albeit indirectly. I could see this being abused by clever hackers, with dialog.close() and dialog.showModal() being called in rapid succession, simply for the purpose of recentering. Sure. As noted above, you could do it from script if you wanted. I was only objecting to supporting it directly, since it doesn't seem like a good user interface. Obviously, authors have found many ways to create poor interfaces over the years, even without explicit support. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] onclose events for MessagePort
On Fri, 13 Dec 2013, Jonas Sicking wrote: On Fri, Dec 13, 2013 at 3:29 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 11 Dec 2013, Jonas Sicking wrote: No sync IPC needed. When a port is pinned, you send an async message to the process which contains the page for the other side. When that process receives the message you check if the page is currently being displayed. If the page has been completely torn down then you send a message back saying that the page is dead and that the promise created during pinning should be rejected. If the page is sitting in the bfcache, you remove it from the bfcache and send a message back saying that the page is dead and that the promise created during pinning should be rejected. If the page is displayed, then you add a flag indicating that if the page is navigated away from, it should not go into the bfcache and that we should send a signal to reject the promise. Obviously if the process had crashed before we were able to process the event, you send a message back to reject the promise. The same thing is done when unpinning. You send a message to the other side saying that it's getting unpinned. This means that it's possible to get a lock, have the other side navigate then go back, then have the other side receive the notification for the lock. It's this that you need blocking IPC to prevent. But I guess we could live with that just being possible. Indeed. The idea with bfcache is that going back/forward should be largely transparent to the page itself. So I think it's fine that it's transparent also to the page that's talking to it in this instance. Kicking the page out of bfcache isn't a goal in and of itself. The goal is to prevent other pages from waiting unduly long for a message. This basically boils down to being able to flip a switch on a MessagePort saying that the port should not be GC'ed and should prevent its owner's pages from being bfcached, right? I'm still very uncomfortable with this idea of preventing either of these. Having a way to prevent GC on objects that would otherwise get GC'ed seems like it would result in leaks, and preventing bfcache seems like it would defeat the entire bfcache idea (consider what happens if some ad networks start using shared workers to make obtaining and showing ads more efficient, and they communicate with the host pages with ports that they block bfcache on -- suddently large parts of the Web would have bfcache defeated). We could allow bfcaching here by introducing the discussed separate features which allow the page to signal that it's fine with being bfcached even though the error was signaled. That way if the page is revived from bfcache it can send a message on the channel saying I'm back now at which point they can resume communicating. How would this work when a page has several libraries (e.g. ads, Facebook like button, Twitter tweet button), each talking to their shared worker, and each with different opinions about whether or not they can handle a bfcache situation? [...] So you'd have: port.onmessage - received a message port.onerror - other side crashed or was terminate()d port.onsuspend - other side went to sleep port.onresume - other side came back Wouldn't this expose GC behavior? If an unreferenced channel is GCed before the page navigates then port.onsuspend is not fired. If the same unreferenced channel is not GCed before the page navigates then port.onsuspend is fired. Yeah. Additionally as the only implementation of a bfcaching browser this is a risky API. In all other browsers, once onsuspend has fired the channel is dead and no events will fire. Right, that's why I hadn't added support for this in the spec. I really don't know what the right solution is here. I had originally added onclose to ports really early on, but we dropped it because it exposes GC. Fundamentlly, I think any solution we come up with here either has to expose GC or block GC, neither of which are a good idea. Same with the bfcache: every solution either has to expose the bfcache or prevent it, neither of which is a good idea. So what can we do? What the spec has now (MessagePort.onerror) only helps for the limited case of a process getting killed by the system; it doesn't help for any of the features of the Web platform like navigation, Worker.terminate(), etc. Maybe the right thing here is for you (browser vendors) to experiment with different approaches to this, and for me to just spec whatever comes out of that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inputmode feedback
On Mon, 27 Jan 2014, Takayoshi Kochi (河内 隆仁) wrote: On Wed, Jan 22, 2014 at 9:54 AM, Ian Hickson i...@hixie.ch wrote: Japanese IME (e.g. Microsoft IME) has several modes for typing characters, divided by the category of the set of characters (kana, half-width-kana, alphanumeric, full-width-latin etc.), each of which has different purpose for representing things (e.g. imported words or computer programs are written in alphabets, while other Japanese text is written in kana and kanji, converted from kana using IME) and switching these submodes are critical part of (at least desktop) IMEs to efficiently type text with several of these sets of characters with alphabet-only physical keyboard. These modes are actually sub-modes of a specific language (Japanese) IME. This sounds similar to how it works for Latin scripts, where for instance you might have one mode for entering numbers and one mode for entering text and one mode for entering URLs. Take a look at a Japanese blog post e.g. http://googlejapan.blogspot.jp/2014/01/google-chrome.html You can see alphabets, numbers and other Japanese characters (hiragana, katakana, kanji) are all used in one entry. This again is similar to how in Latin script prose you might find segments with URLs, others with tables of numbers, and others with text, all combined into one document. So for completing the feature parity for Japanese web users against native applications, these modes has importance but we think inputmode is not an appropriate place to put it on. Given how identical they sound to the latin script features exposed by inputmode=, I don't understand why inputmode= would be the wrong place for this. It sounds eminently applicable. For one thing, such Japanese IME submodes are dynamic by nature (user can move from one to another with some key combinations or via IME menu). When user move focus from one field to another, the submode is persistent. This is an implementation detail, right? I mean, if a user wanted to create a platform where the IME defaulted back to kana whenever a new control was focused, that wouldn't be wrong, it would just be a choice they would have to implement, no? E.g. You have a form: Zip: [] - alphanumeric Address: [] - kanji (kana) Building: [] - kanji (kana), and maybe numeric for building/room number etc. Name: [] - kanji (kana) Tel: [] - number Without any inputmode or alike, you start from zip code, you turn off IME (if it's on) and type in zip code, then press tab to the next field, IME is still off, you turn on IME to fill address, type in building and name. At the Tel field, you have to turn off IME (or change IME submode to half-width-latin) manually, because the IME submode (at this point, most probably in kana mode) persists. Right. This is the kind of thing we're trying to solve. It's identical to the same problem in Latin script pages: you'd start from the ZIP code, switch to digit mode, type in the ZIP code, tab to the Address field, switch back to text mode, type that in, etc. At the Tel field, you'd have to switch back the digit mode. With inputmode=, we avoid this; the ZIP field starts in numeric mode, the Tel field starts in a dedicated Telephone mode, the Name field starts in the text mode but with automatic capitalisation since names in Latin text are usually capitalised, etc. If inputmode has these Japanese IME submodes (it does), users can save switching modes manually when hopping from one field to another. Usually Japanese users are accustomed to changing these modes manually, so if the mode changes automatically, it may cause a surprise, but use cases such as inputting a lot of entries for address book repetitively, it would save the mode switching much. Right, that's the idea. That said, though inputmode is useful to declaratively write the default expected submode for the field to be initially in, once user manually change the mode from the initial submode, it is not apparent how should the browser behave when user re-focus that field? Browser implementer can have several choices here: 1. Change the IME mode to what is specified as inputmode. 2. Remember the last mode when the focus was there and restore the mode. 3. Do nothing, if the mode of the field manually changed to something else. 4. none of the above(?) Same as with latin script input modes, right. This is an implementation choice. Personally I would recommend restoring whatever input mode was used when the user last had that field focused, resetting when the page is reloaded. But you can do things more or less clever here, or have it configurable, or whatever you want. The idea, in HTML, is to provide hints to the user agent so that the user agent can use the information about the page (this is a numeric field, this is for a Latin name, this is for kanji text written using kana) to provide the most helpful interface
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
. There would be a protocol for validators to speak, which would have to have at least the following API features: - Get a list of all the registered keywords, and their current state, and information about when the last change was made. - Add a keyword. - Notification that a new type has been added or the state of an existing type has been changed. This is a proposal; I haven't set anything up to do this yet. I would be interested in knowing whether people see any problems with this, or see any better ways to address the underlying problems listed earlier (or indeed, if people think the problem description is incomplete or wrong). We could do more clever things, for example, checking that the provided spec link actually contains the relevant keyword name. I'm not sure if it's worth it, but it might be interesting to do. Another thing that we could look at is the metadata _values_. Right now, we're not doing any checking at all of the content= attribute, but many of the keywords have limited value spaces that we could check. It's probably best to have the validators implement checking for the conforming interoperable good practice keywords explicitly, though, rather than trying to make this more generic. The above is mainly focused on meta, but many extension points need serious work, not just meta name. link rel, for instance, but also Content-Type, URL schemes, etc. I think we should probably start with meta name, and move forward from there once we have more experience with that one, since that's the only one for which the WHATWG is alone in trying to document the name space. Once we've proven that the model works, assuming it works, we can approach other registries and show them our experience. (And if it doesn't work, then we can keep trying to work on meta name instead.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, 7 Jan 2014, Dominic Mazzoni wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch wrote: If the user needs a big ring, it seems bad for us not to render one. Especially since we can know this. Yes, there are users who need extra high-contrast focus rings. But no, they don't get that from an operating system setting that the app queries, I think that's the source of the confusion. Try checking the Make the focus rectangle thicker checkbox in Windows. Any time where a single-pixel dotted outline was shown before, you'll now see a 2-pixel dotted outline. However, in every application I tried, when previously you saw a custom focus highlight (which is the majority of the time - the dotted outline looks very dated), there's no change - including in Windows explorer, Office, IE, Firefox, etc. - I just don't see any precedent for applications that already provide custom focus highlighting to do something different when the Make the focus rectangle thicker option is checked. Why isn't this just a widespread accessibility bug? If you want to give the AT position information when there's no visible focus ring, that's what addHitRegion() is for. For the record, I like addHitRegion and I'd like to go forward with implementing it too. Do you consider it ready for implementation? Yeah, I'm not aware of any outstanding work for it right now. Have any other browsers expressed interest? I do not recall specific comments from browser vendors one way or the other. The impression I got a while back was that there were still concerns from some people. I'm not aware of any outstanding concerns. We should probably start a new thread on addHitRegion if there's anything to discuss, and keep this one focused on drawSystemFocusRing, since that's the one that it appears three browsers have implemented now. (I'm assuming IE is implementing it, given that Microsoft has publicly commented on the spec.) The reason I think it's relevant is that if what people want drawSystemFocusRing() to do is in fact what addHitRegion() does, then we should not do both. It wasn't my intent to implement something different than the spec. The spec only talks about the accessibility part of the implementation in a Note explaining the meaning of Inform the user, which I didn't think was normative. I took the language in that note as a guide but ultimately tried to implement something that actually works. I made a simple demo app to demonstrate the use of this API, and tested it with three screen magnifiers while developing it. I apologise that the spec was misleading in its note. I've tried to update the spec to remove this confusion (and made the new paragraph normative.) I think in practice it may be that for accessibility the right thing is for authors to use addHitRegion(), and the focus ring drawing APIs should only draw the focus ring and do nothing else. On Tue, 7 Jan 2014, Rik Cabanier wrote: On Tue, Jan 7, 2014 at 9:45 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 7 Jan 2014, Rik Cabanier wrote: I believe this is where part of our confusion/disagreements come from. The draw*FocusRing methods are NOT direct-mode APIs for *a11y*. Right. They're not really APIs for accessibility at all. They're about drawing focus rings. No. The only reason for this API is accessibility. That was not the primary intent of the APIs. (Accessibility, like security, performance, or internationalisation, is almost never the primary intent of a well-designed API, since accessibility, like security, performance, and internationalisation, are concerns that permeate _every_ API and well-designed APIs make them non-issues.) An author could just check the focused state and draw the ring himself; there's no need for an API to do this. There's no way to draw a focus ring that has the appearance of the platform's focus rings without an API for it. By calling draw*FocusRing on a fallback element, the a11y software will now associate that element (and its aria rules) with the path that was in the canvas' state. This is non-conforming behaviour that is incompatible with the API design. Doing this will cause harm, because the API is incapable, as designed, of being used in this manner correctly without causing bugs. For example, if, when an element is not focused, it's split into four parts, there's no way to draw a single focus ring around it. Thus the data about that control's position _will be incorrect_ if the UA relies on this method for this data. I don't understand. The path for the focus ring can be anything, including multiple closed paths. The data for the a11y software won't be wrong, it will be the boundingbox of those paths. Right. If the intent, however, is for one part of the element to be magnified, and the other parts to just be decorative, then this would result
Re: [whatwg] Adding obsolete elements/attributes to indexes
On Thu, 23 Jan 2014, Simon Sapin wrote: To help with discoverability of obsolete features by implementers, I’d like them to be included in the Index section’s tables. They're explicitly excluded to help with avoiding their discovery by authors. There's a link from any interface that has obsolete IDL members to the partial interface that defines those members. As far as non-obsolete elements go, I think the only requirements in the obsolete section are regarding these obsolete IDL members. When considering what Servo should implement, I mistakenly concluded that li elements do not have a 'type' attribute, based on the Index. They in fact do, as specified in the Obsolete features section. Do you mean a type IDL attribute or a type content attribute? No IDL attributes are listed in the index. I don't know what it really means for an element to have a content attribute, from an implement's persective. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should ambiguous ampersand be a parse error?
On Tue, 10 Dec 2013, Boris Zbarsky wrote: On 12/10/13 11:11 AM, Peter Cashin wrote: Is the specification intended to have compliant HTML agents stop parsing ambiguous ampersands? Compliant HTML agents are allowed to do so, I guess, per the technical rules about parse errors, just like for any other parse error. But I expect that this is at least partly for conformance classes other than browsers; all browsers press on through parse errors in HTML. Maybe the allowed behavior for parse errors should be made conditional on conformance class... While I agree that it's unlikely that any browser will ever make use of this in its default mode, I've still allowed it, because it can be a useful mode to use in an authoring or educational environment. On Tue, 10 Dec 2013, Jukka K. Korpela wrote: Authoring requirements as such are just policy statements, therefore regularly ignored. Conformance requirements for authors are really just a way to try to help authors avoid making what they would consider mistakes. The specification actually has a whole section that explains why we bother to have them: http://whatwg.org/html#conformance-requirements-for-authors Allowing user agents to stop parsing after a parse error (BTW, where exactly does the WHATWG HTML Living Standard allow that?) It's in the sentence that follows the one that defines parse error: http://whatwg.org/html#parse-error is really just avoidance. Not sure what you mean by avoidance. What does it avoid? If browsers actually apply some specific error recovery, what’s the excuse for not making that mandatory? We allow these two implementation strategies because not all tools actually need to recover. For example, an HTML publishing pipeline might want to assume that its input is valid, and simply refuse to handle invalid input, rather than applying the error handling rules (which can cause a big mess, e.g. reordering content!). Different user agents can really do very different things. But I don’t think it’s a good idea to make that a rule of *parsing HTML*. It's not really different things, it's either doing what the spec says, or aborting early. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
On Wed, 22 Jan 2014, Daniel Holbert wrote:
Boris Zbarsky and I ran across a not reflecting reality issue in the
WHATWG HTML spec.
The spec currently defines the rendering of the br element as follows:
# br { content: '\A'; white-space: pre; }
Source:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1
This CSS implies that br's rendering could be customized by CSS, which
in practice (in the browsers that I tested[1]) is not actually the case.
Yeah, this is intentional. The spec is trying to point the way for
browsers to go in. :-)
Right now, 'content' isn't even defined as applying to elements; the HTML
spec is relying on somewhat well-established theory for future expansion
of the 'content' property. The idea is that, on the long term, we can
explain br in terms of regular CSS. (I similarly hope we can do this
with form controls, but form controls right now have behaviours that can't
even be explained by theoretical CSS, as far as I can tell.)
In particular: given the spec's CSS quoted above, you might expect that
perhaps an author could set...
white-space: nowrap
... on a br element, to neuter the linebreak. That doesn't work,
though -- the br still triggers a linebreak.
Right. If allowing this isn't Web compatible, then I guess we'll have to
change.
Similarly, you might also
expect to be able to customize the 'display' or 'height'/'width' or
'background' properties, but in practice, none of those have any effect
on br in modern browsers.
In isolation, 'height' and 'width' would have no effect (they don't apply
to display:inline elements) and 'background' would not have a visible
effect (the element has no effective width). 'display', though, in theory,
should have an effect. If allowing this isn't Web compatible, then I guess
we'll have to change.
My hope is that we can limit what needs to have no effect, so that on the
long term br becomes less and less magical. But naturally this depends
on what is Web compatible.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 2D canvas feature proposal: text decoration
On Mon, 30 Sep 2013, Justin Novosad wrote: On Fri, Sep 27, 2013 at 5:05 PM, Ian Hickson i...@hixie.ch wrote: Text decoration can theoretically be drawn directly by the application by using font metrics to compute decoration positions, but this is often very complex to do correctly in a truly portable way. We could add underline metrics to TextMetrics if that would help. Perhaps that would be the right solution, but I don't know enough about metrics to authoritatively state what information is missing. The fact that most browsers do not fully support the text metrics as currently spec'ed does not help either (I know, Chrome is one of the worst offenders w.r.t. metrics support). Sure. They don't support drawing underlines either. Browsers typically don't support features when they're added to a spec, except for cases where the spec is describing proprietary features that ended up being adopted by other browsers as well. If doing things with CSS and the DOM is too slow, then we should fix that, we shouldn't just tell people to rewrite their apps in canvas. Easier said than done. Well, sure. Most things here are. In theory, it should be possible to obtain canvas-like performance when DOM usage is constrained to styles that make layout calculations trivial (as in no-op). It's quite possible that the solution is not to use DOM, but to provide some different mechanism that is more structured and semantic than canvas but more rigid and less flexible than DOM. However, this is still a more or less unsolved problem despite the best efforts of a large number of very smart people. Let's not hold our breaths. Well, no, let's solve it instead. Having people move from a high-level, highly flexible, semantically rich, media-independent model to a low-level, medium-specific, mostly semantic- free model just because of performance issues seems like a huge loss. Solving this means working out the use cases we want to address, figuring out what the requirements are, and then coming up with models to address them. So let's do that. First, what are the use cases we want to address? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas resetClip() API
On Tue, 8 Oct 2013, Simon Fraser wrote: I don’t like the resetClip() API, and don’t think it should be added to canvas. The reason resetClip() is a bad API is that it breaks the ability to robustly modularize drawing code. For example, say that you have the following code: context.save(); // … set up a path to clip to context.clip(); someJSLibrary.drawSomething(); context.restore(); In the absence of resetClip(), you are guaranteed that someJSLibrary.drawSomething() can’t draw outside of the clip you specified. With resetClip(), that JS library can draw wherever the heck it wants, which may totally break your canvas drawing. That's true anyway; for example, the JS library could call context.restore() to escape your clip(), or could call save() more times than it calls restore(). At the end of the day, you have to have a contract with your library, and in that there might be you obey my clip or you obey my transforms or you obey my transforms but it's ok if you unclip or whatever. If you really need resetClip() in your own drawing code, you’re probably doing it wrong. Why is it more wrong to need resetClip() than to need resetTransform()? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inputmode feedback
keyboard or on-screen handwriting recognition widget, a desktop computer might use a fully-fleged IME system, a speech-based system might do everything using speech recognition and use the input mode to decide what dictionaries to use for recognition and what scripts to use for transcribing the results. Exposing all these aspects to the author is a losing proposition: authors would frequently make mistakes, forget certain classes of users or devices, fail to test on all possible platforms, etc. The solution is to use the high-level semantic approach used elsewhere by HTML, and thus just provide a high-level description of the kind of input that is expected, letting the user agent translate this into the appropriate settings for the OS-level input system. On Mon, 16 Dec 2013, Michael[tm] Smith wrote: As I commented in bug 23961, the value of the inputmode attribute was originally specified as taking a list of tokens, where one token is optionally the name of a script like latin and the rest of the tokens were optional modifiers. So you could imagine a value like inputmode=latin titlecase prediction. I'm not saying I think the use cases actually merit changing the inputmode microsyntax to be a list of tokens like that. But it might be preferable to introducing yet more attributes. We originally had this in Wbe Forms 2.0, but it is far more complex than necessary, IMHO. Authors don't need that level of control in the vast majority of cases. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Simplified picture element draft
On Tue, 7 Jan 2014, Boris Zbarsky wrote: On 1/7/14 12:01 PM, Yoav Weiss wrote: I'd love to get some more details regarding that. I'll start a mozilla.dev.platform thread on the subject, since it's Gecko specific. It's actually not entirely Gecko-specific. Consider a display:none iframe. How should viewport-size-related media queries be evaluated in such a thing? The specs don't define it, as far as I can tell. In fact, the specs don't actually define anything useful for the viewport of a framed document at all, as far as I can see. CSS just assumes a viewport exists, and HTML doesn't define anything about frames setting up a viewport for the document inside them... But say they defined it. How would the viewport of a display:none iframe be defined, exactly? Last I checked, UAs just end up doing wildly different things in this situation. IMHO this should probably be in the CSS spec, but I'm happy to spec something if CSS doesn't want to pick this up. It's probably just a matter of saying, in the rendering section, that nested browsing contexts that aren't _being_rendered_ (or that are frames outside framesets) get a 0x0 viewport. (Viewports that are being rendered seem to have an unambiguous dimension, but let me know if I'm missing something here too.) Right now, Chrome and Firefox seem to report 0 as the body.offsetWidth for a hidden iframe. (Couldn't get a result for Safari; don't have IE here.) http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2725 For Chrome (since it puts data: in the wrong origin) http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2726 For Firefox (since for some reason the message in 2725 isn't sent?) Can you elaborate on the widly different things? What should I be testing? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Wed, 16 Oct 2013, Dominic Mazzoni wrote: On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson i...@hixie.ch wrote: WCAG 2.0 claims that many platforms allow the user to customize the rendering of this focus indicator, though I admit that I don't see any references for this claim: http://www.w3.org/TR/WCAG-TECHS/G165.html IBM similarly claims users may customize the default indicator in Windows to a brighter color: http://www-03.ibm.com/able/guidelines/web/webfocusvisible_aa.html#tech3 I haven't been able to support those claims. However, Win32 in particular has some APIs for changing focus rings (see below for references). If the user changes the focus ring's color and/or width, then drawSystemFocusRing should draw using that style. Right. As far as I can tell, it's not generally the precise colour that a user picks. It's the dimension, and the rendering mode (high contrast vs normal). The issue is when the application wants to draw its own focus ring - should the system sometimes override that and draw its own focus ring instead? That's the argument I don't buy. If the user needs a big ring, it seems bad for us not to render one. Especially since we can know this. Respecting the system focus ring color but ignoring the rest of the system palette makes no sense. A single solid-colour focus ring does have that problem, yes. This is the case even without canvas; if you change your page colour scheme and don't override the focus outline colours, and the operating system's default focus rings are solid colour, then you can have this problem. The solution is for the focus rings not to be a solid colour. Mac OS, for example, makes them a gradient. Some vesions of Windows draw the focus ring using xor (I haven't checked modern Windows behaviour). Mouse cursors are commonly drawn using two levels of outlines to avoid the equivalent problem with mouse cursors. A high contrast focus ring should be visible regardless of the background. I am totally in favor of trying to provide a better experience for users who want a high-contrast theme and custom focus rings - I just don't think this API is the way to achieve that goal, and I think it would actually make things worse if user agents implemented it as specified. I don't understand why it would make things worse, but I'm certainly open to better suggestions. What's a better way to get authors who don't care about accessibility to honour high-contrast focus ring preferences? Perhaps this shouldn't even be solved as part of canvas. Maybe we should add web apis to indicate that the user prefers a custom color scheme that could be used for rendering the whole page, not just canvas. Most authors will just ignore this. That's why we have user style sheets that can override author sheets, for example. The name isn't ideal, it's true. I don't know what a better name should be, though. It's really let me know if I should draw a focus ring, and if I should, then take the opportunity to also notify the accessibility tools, which doesn't make for a very pithy method name. What would you call it if it never draws, but just notifies the UI? At that point, it would just be the addHitRegion() API, with a check for whether the control is focused. Not much point having that as a single rolled-up API, IMHO. It's canvas-specific because in the non-canvas state, the browser already does this, in theory. The focus in the non-canvas case is drawn by the browser using the :focus rules, which, in principle, are set to the user's preferred state. In practice this doesn't necessarily work for the same reason I gave above: the system focus ring might look terrible in particular UIs. The point isn't for it to be aesthetically pleasing, the point is for it to be more obviously visible to the user. If we added a canvas fallback element as a parameter to scrollPathIntoView, I don't think we'd need drawCustomFocusRing. I don't understand how this would work. Suppose you have a control that is floating around the screen. You need the keyboard-focus-driven magnification to follow this control while it's focused. You don't want to scroll to that control every time it moves, you only want to scroll to it when it's focused. So what you do is when it's focused, you scrollPathIntoView(), and then every 16 milliseconds you move the control and redraw its focus ring, by calling drawCustomFocusRing() (or drawSystemFocusRing() if you don't care exactly what it looks like), and that updates the AT. Wait, so what's wrong with calling scrollPathIntoView on it every 16 milliseconds, only when it's focused? It would prevent the user from scrolling the page, which seems like a pretty serious problem. drawCustomFocusRing() and drawSystemFocusRing() shouldn't cause anything to scroll. That would be very confusing, IMHO. (When would you
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, 7 Jan 2014, Rik Cabanier wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch wrote: I don't see that as an argument against caching the last known location of an object too. If you want to store state, that's what addHitRegion() is for. It's the retained mode API for canvas. The draw*FocusRing() methods are direct-mode APIs. There's no expiry logic, there's no API contract that implies that the calls will be made, or made correctly, if the element isn't focused. I believe this is where part of our confusion/disagreements come from. The draw*FocusRing methods are NOT direct-mode APIs for *a11y*. Right. They're not really APIs for accessibility at all. They're about drawing focus rings. By calling draw*FocusRing on a fallback element, the a11y software will now associate that element (and its aria rules) with the path that was in the canvas' state. This is non-conforming behaviour that is incompatible with the API design. Doing this will cause harm, because the API is incapable, as designed, of being used in this manner correctly without causing bugs. For example, if, when an element is not focused, it's split into four parts, there's no way to draw a single focus ring around it. Thus the data about that control's position _will be incorrect_ if the UA relies on this method for this data. This is why addHitRegion() exists; it provides this data in a usable manner. This HAS to be stateful because the a11y software queries the browser for the bounds of the fallback element to draw its own focus rectangle. The paths provided by the draw*FocusRing() methods aren't useful for this purpose. Using them for this purpose is bogus. The paths provided to those methods are only useful for direct-mode painting and direct-mode notification to an AT API if such an API accepts direct-mode notifications. If it doesn't, then the addHitRegion() API is what should be used to send the notifications. For the blink and firefox implementations (and the webkit patch) informing the user [1] means telling the DOM about the region of the fallback element so the a11y software can query it later. That's not conformant, and will lead to accessibility problems. Informing the user is an imperative action, not an indirect action involving caching state over multiple frames. Because of this, there also needs to be a way to disassociate the region from the fallback element (ie by having no current path when you call draw*FocusRing) Yes, if draw*FocusRing() were the API you describe, we would need such a thing. The API you describe, however, is not draw*FocusRing(), it's addHitRegion(), and it already has such a thing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 6 Jan 2014, Rik Cabanier wrote: I think you misunderstood. The drawCustomFocusRing() and drawSystemFocusRing() don't cause scrolling, it's when you focus the fallback element that the browser should scroll. Doing this would imply remembering where the control was the last time the focusing ring was rendered, which would cause all kinds of problems for authors. Since the last time the control was rendered, maybe the rendering stopped showing the control, or maybe when it was last rendered, the control was rendered just off-screen on purpose so that it could be animated onto the center of the screen when focused... we simply can't know what the author is doing. This is why there's a separate dedicated API for scrolling. If the author thinks that the user will want to scroll to the control when the control is focused, then it's trivial to do. But we should not force this behaviour. That's terrible API design. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 6 Jan 2014, Dominic Mazzoni wrote: I understand that the addHitRegion APIs are the intended way to specify the permanent location of a fallback content element. But practically speaking, it makes far more sense to cache the bounding box of each element when you call draw*FocusRing, otherwise you end up with a timing problem, because as soon as you focus the fallback element, the screen magnifier immediately wants to know its bounding box - but drawSystemFocusRing may not get called until sometime later, when the app decides to repaint - and by then it's already drawn the bounding box in the wrong location. Some magnifiers respond to a location change event, but others don't, requiring an ugly hack like sending a second focus event, or delaying the first one. The paint is going to come within 16ms (unless the app has high latency, in which case it'll be unusable anyway). That's when the magnifier should be updated, not when the focus moves in the HTML document. The simplest implementation of the current spec to cache the bounding box when you call drawSystemFocusRing and return whenever the assistive technology requests the bounding box of that fallback element, whether it's focused or not. I know it isn't exactly what was intended, and addHitRegion will be a more powerful solution, but I don't see the harm in implementing it this way. The harm is what I described in the earlier e-mails. You are likely to end up zooming on the wrong thing. For example, if the app only renders the focused element, and puts it in a random place when it's focused, you'll draw the bounding box wherever the control was last time it was rendered, which may have nothing to do with where it'll be this time. Similarly, if the control is moving, but you only update the bounding box when the control is first focused, then you'll leave the magnifier behind. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comments on dialog
On Wed, 18 Dec 2013, Brian Blakely wrote: On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson i...@hixie.ch wrote: I've added a rule to the spec that says that viewports have to be pannable so you can see all of a dialog, but I don't know how feasible that really is. I could see implementations using shadow divs to satisfy this It might be beneficial to even codify kind of element as ::modal, representing a modal layer acting as an ancestor for both the ::backdrop and dialog. Not really sure how this would work. Can you elaborate? 3. When the modal dialog's height changes, either due to CSS or content changes, the vertical position of the dialog should change (unless the height exceeds the viewport height). That's an interesting idea, but I'm not convinced it's the right answer. Having the dialog move up and down when stuff is added at the bottom would be quite weird. You can always implement this manually from script. To go back to hacky and rather difficult-to-maintain JS techniques for something so simple seems antithetical to the intention of dialog to me. Modern modal implementations don't require that. My point isn't that we shouldn't offer the feature because it is already possible. My point is that this feature is actively bad. I'm saying I don't think it's good UI for the dialog position to change when it increases in height. It looks like Blink's implementation will recenter the modal when show/showModal are called. That's per spec, yes. The suggestion above was regarding when the dialog changes size while it's already visible, I believe. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Tue, 17 Dec 2013, Ami Fischman wrote: Recently https://www.w3.org/Bugs/Public/show_bug.cgi?id=23263 Navigator acquired the ability to enumerate media output devices (in addition to input devices): http://dev.w3.org/2011/webrtc/editor/getusermedia.html#enumerating-devices What's the privacy story for this API? It would be nice to allow media elements to direct their output to such an output device. The primary use-case is to allow app UI/script to select which audio output device should play the audio track of a video or audio tag (wired speakers, bluetooth headset, etc.). Seems reasonable. Is any other browser vendor interested in implementing something to address this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comments on dialog
On Sat, 2 Nov 2013, Brian Blakely wrote: On Sat, Nov 2, 2013 at 5:29 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 2 Nov 2013, Brian Blakely wrote: 1. When a modal dialog is active, the user can still scroll the underlying page. Why is that a bug? By its nature, a modal view blocks interaction with the underlying content. It's also inherently disorienting. Imagine opening a modal, accidentally scrolling the underlying page while interacting with said modal, then closing the modal and seeing something totally different from before and not understanding why. This happens today with the majority of our lightbox plugins, and we have the opportunity to fix it now. I've changed the spec to make the ancestors of dialogs inert, so this should be fixed now. 2. Even if the root element has overflow hidden, it should be possible to scroll the modal layer when a dialog escapes the boundaries of the viewport (or iframe). Why? Isn't the whole point of 'overflow: hidden' on the root element to prevent the ability to move the viewport? You can always but the overflow property on a child of the body, e.g. a fixed positioned div. Then the scrollbars would be hidden for the div, but the viewport could still be moved for dialogs. div wrappers are what we use today, and are what dialog should be alleviating. Maybe ::backdrop should be a pseudo-parent for dialog, with overflow: auto by default. At the very least, that would be a much more flexible solution going forward. This is an interesting issue. Right now, arguably, even if the dialog isn't 'fixed' and the viewport isn't 'overflow:hidden', it's not clear that you can scroll if the dialog doesn't fit, because of the fix to the problem described above -- it's the same scrolling mechanism that scrolls the view of the dialog as scrolls the parent's contents -- in fact, the dialog is just part of the parent's contents. I'm not sure what the right answer is here. For dialogs whose containing block is the initial containing block, maybe we can require that, as a special case, the browser allow the viewport to be moved around to view the dialog (but then what happens if it _is_ overflow:hidden and the dialog goes away? Does it snap back? What about the background, what do we show in the parts the author never intended to have visible?). But what about when the dialog is in a div with overflow:scroll, if it's not absolutely positioned? I guess that's a rare case (and you can't position a dialog inside an overflow:scroll element because of the rule about the containing block for dialog elements), so maybe we ignore it. I've added a rule to the spec that says that viewports have to be pannable so you can see all of a dialog, but I don't know how feasible that really is. 3. When the modal dialog's height changes, either due to CSS or content changes, the vertical position of the dialog should change (unless the height exceeds the viewport height). That's an interesting idea, but I'm not convinced it's the right answer. Having the dialog move up and down when stuff is added at the bottom would be quite weird. You can always implement this manually from script. To go back to hacky and rather difficult-to-maintain JS techniques for something so simple seems antithetical to the intention of dialog to me. Modern modal implementations don't require that. My point isn't that we shouldn't offer the feature because it is already possible. My point is that this feature is actively bad. I'm saying I don't think it's good UI for the dialog position to change when it increases in height. On Tue, 17 Dec 2013, Matt Falkenhagen wrote: On Fri, Sep 27, 2013 at 7:15 AM, Ian Hickson i...@hixie.ch wrote: I started doing this, since several people have asked about this and it seems the consistency between showModalDialog()/close() seems less interesting to people than the consistency with open everywhere else. However, it turns out this would make the show() method clash with the open IDL attribute on dialog, which we want since it matches the name of the open= content attribute which matches details open. Note that window.open() and document.open() don't really do the same as this method does, either. window.open() creates a new Window, or navigates and existing one; document.open() resets the document. dialog.show() just changes the dialog to be visible. Also, there's an interesting mix in other APIs. (Disclaimer: I don't know many of these APIs personally, so I may be misinterpreting their documentation wildly. I basically looked for terms like open and close in the docs and tried to see what the right methods were in each case. I only included methods for modal dialogs if there was a trivial method; many APIs have to be configured to make dialogs modals separately.) Android uses show() and dismiss
Re: [whatwg] Reporting mid-stream resolution change on video
On Thu, 12 Dec 2013, Ami Fischman wrote: On Thu, Dec 12, 2013 at 2:56 PM, Ian Hickson i...@hixie.ch wrote: I suppose we could fire resize on initial load as well. I guess it depends on what code that uses this looks like. Is the initial size change the same kind of code as resizing, or is it different code? (e.g. will one set up elements to frame the video while the other just changes their size?) Yes, I think that the first size event and subsequent ones are similar enough that the initial size info should be fired when metadataloaded fires. Example use-cases: - a chat service wants to display an HD emblem on video feeds above some threshold (and removed it if/when they fall below the threshold). You want to show/hide the emblem from the first point at which you have size information, and each time that information changes. - an on-screen display (OSD) for feed resolution; needs to be updated on resize as well as initial size information. In fact I am failing to think of examples where only not-first resize information would be needed. Ok. Done. (The initial one fires just after the 'durationchange' event and just before the 'loadedmetadata' event.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] onclose events for MessagePort
On Wed, 11 Dec 2013, Jonas Sicking wrote: On Wed, Dec 11, 2013 at 3:54 PM, Ian Hickson i...@hixie.ch wrote: I really don't understand why we'd want that level of complexity for something that we can solve with just a single event handler, though. The problem, as described, is just we need to know when a remote port is killed due to an OOM error. The event handler does this. Why do we need to complicate it with two-way metadata messages to pin workers and so on? I really don't understand what that gets us. Starting with this since there seems to be misunderstanding about use cases. The use case here is a page (or a worker) sending a message through a message port and wanting to know if the other side disappears before it is able to respond. There are a few scenarios where the responder could disappear. 1. The process where the responder lives could crash. 2. The responder could be running in a dedicated Worker which was terminated through Worker.terminate(). 3. The responder could be a web page that the user navigates away from. 4. The responder could be a dedicated Worker which is owned by a web page that the user navigates away from. Well, if we want to support these then I agree that the only workable solution is one where you can essentially buy a lock that prevents the other side from getting bfcached until it's replied, such that if it is suspended (for workers) or navigated (for browsing contexts) before it receives the message saying the lock is released, it instead just gets discarded permanently. It does seem pretty lame that we would allow any random page you communicate with to be able to prevent you from bfcaching, but I don't know what we do about that. So I hope that describes the use case, and that it also describes the dedicated workers issue. I did actually consider these use cases, I just didn't address them because exposing the bfcache logic or allowing pages to prevent bfcaching seemed like a bad idea: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Dec/0062.html No sync IPC needed. When a port is pinned, you send an async message to the process which contains the page for the other side. When that process receives the message you check if the page is currently being displayed. If the page has been completely torn down then you send a message back saying that the page is dead and that the promise created during pinning should be rejected. If the page is sitting in the bfcache, you remove it from the bfcache and send a message back saying that the page is dead and that the promise created during pinning should be rejected. If the page is displayed, then you add a flag indicating that if the page is navigated away from, it should not go into the bfcache and that we should send a signal to reject the promise. Obviously if the process had crashed before we were able to process the event, you send a message back to reject the promise. The same thing is done when unpinning. You send a message to the other side saying that it's getting unpinned. This means that it's possible to get a lock, have the other side navigate then go back, then have the other side receive the notification for the lock. It's this that you need blocking IPC to prevent. But I guess we could live with that just being possible. I strive for a higher bar than just no objections. Certainly though I welcome further input from everyone else here. Your proposal doesn't even meet this bar. True. A better way of putting it is that I strive for an orthogonal bar. But that's another story. But more importantly, your argument that it's too burdensome to implement doesn't carry much weight when no actual implementors has expressed that concern. This I disagree with. I have many times been in situations where we've discussed something, come up with a solution, had nobody object, specced it, implemented it, shipped it, and then years later had other implementors complain about the complexity. If something can be solved with a simple event, then having a complex API is not a good idea. In this case, though, if we want to solve all the problems you listed, a simple event isn't going to cut it, indeed. Anyway. If we do want to address use cases 3 and 4 above, then I agree that the event in the spec today isn't sufficient. I'm not sure a promise makes a lot of sense as an alternative, though. To make that work, you'd need to have the UA reject the promise but the author resolve it, which seems kind of unusual for promise-based APIs. You also end up, as author, being simultaneously the consumer of the promise and the resolver, which is a bit weird too. Also, I'm not sure it really solves all the use cases. As an author, one of the ways in which I use channels (in any environment, so not just those that use MessagePorts, but also e.g. linux pipes, WebSockets, etc) is as a notification
Re: [whatwg] Reporting mid-stream resolution change on video
On Thu, 12 Dec 2013, Ami Fischman wrote:
Today the video tag exposes video{Width,Height} attributes that allow
the page to discover the resolution of the playing media once
metadataloaded has fired. However there is no way for the page to find
out that the media resolution has changed mid-stream (short of polling
the tag constantly, which is obviously unappealing).
Examples where mid-stream resolution change can happen include:
- WebRTC up/down-scaling a video stream at the source to adhere to
available bandwidth or other requirements
- MSE shifting between quality levels of source material
- Static/VOD/classic video files that change resolution mid-stream b/c of
different source material being concatenated together.
One way to enable this would be to add a metadatachange event to the
list of media elements events (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#event-definitions
).
(this has come up recently in a public-webrtc
threadhttp://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0040.html,
and previously in private discussions)
Seems reasonable. Done. (I used the 'resize' event since it is well
established as the appropriate event to use when dimensions change.)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Specify Location.ancestorOrigins
On Thu, 12 Dec 2013, Philip Jägenstedt wrote: https://bugs.webkit.org/show_bug.cgi?id=83493 It looks like this fell off the radar, because I can't find it in any spec. The reason I noticed is that it's implemented using DOMStringList in Blink, an interface which I also can't find a spec for... The feature request bug for this is: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22699 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Reporting mid-stream resolution change on video
On Thu, 12 Dec 2013, Ami Fischman wrote: Thanks Ian. My reading of http://html5.org/tools/web-apps-tracker?from=8346to=8347 is that a simple video that never changes size will never see the new resize event. Is that intentional? Correct. (I ask b/c e.g. durationchange _is_ fired right before metadataloaded; I'd expect resize durationchange to act similarly in terms of whether they fire on initial load) Would it make sense to make resize fire right before metadataloaded fires and remove its Preconditions (both mimicking durationchange)? I suppose we could fire resize on initial load as well. I guess it depends on what code that uses this looks like. Is the initial size change the same kind of code as resizing, or is it different code? (e.g. will one set up elements to frame the video while the other just changes their size?) Related, it's strange to me that At this point, resize events can start firing. but readyState is still HAVE_NOTHING, which is precluded by http://www.whatwg.org/specs/web-apps/current-work/#event-media-resize's Preconditions. The non-normative note there isn't strictly true; the events can't actually fire until the whole task has finished. It's like the note in the next step, which doesn't mention that the event in question fires later. Notes often trade precision for brevity; if they were as precise as the normative text, they'd be as long as the normative text and wouldn't help. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
