Re: [whatwg] Knuth and Plass algorithm; boxes glue penalties
David Young wrote: I'm wondering if anyone is developing web standards and prototypes for web layout using the Knuth and Plass algorithm? It seems like responsive designs could be expressed more simply in a boxes-glue-penalties frame, and responsive layout for JavaScript, CSS, and other things that you put in pre, now, would be tractable with the right HTML/CSS primitives. If you have something like this underway, please get in touch. On Wednesday, April 08, 2015 6:56 AM Håkon Wium Lie replied: [...] However, it seems you're not primarily thinking of line-breaking, but box stacking on a more general basis? I have discussed such things over the years with the SVG Working Group, thinking that content like geographical information (like words or numbers) being drawn to and repelled by associated geometric features (like lakes or country boundaries) would make a lot of sense in terms of scaling of such content. SVG, has for now, relied on the simpler CSS box model, though models that use simple physics are now more computationally feasible. Here's a relatively recent excursion into the domain of non rectilinear layout: http://cs.sru.edu/~ddailey/TGW2014/RectilinearMold2.html Cheers David
Re: [whatwg] HTML tags.Panorama, Photo Sphere, Surround shots
Sent: Monday, November 17, 2014 1:10 PM Tab Atkins Jr. wrote: To: Biju Cc: whatwg Subject: Re: [whatwg] HTML tags.Panorama, Photo Sphere, Surround shots On Sun, Nov 16, 2014 at 4:38 PM, Biju bijumaill...@gmail.com wrote: New cameras/phone cameras comes with Panorama, Photo Sphere, Surround shot options. But there is no standard way to display the image on a webpage. Can WHATWG standardize it and provide HTML tags. Photo Sphere https://www.google.com/maps/about/contribute/photosphere/ Surround shot http://www.samsung.com/us/support/faq/FAQ00057110/74008 These are just alternate image formats, yes? In that case, browsers can expand their img support to allow pointing to these kinds of files. They'd need some sort of native controls on the img element, I suppose. --- I remember raising a similar issue with W3C/WhatWG/HTML5 WG circa 2007. At the time I seem to recall language in the spec that said img formats (and perhaps by extension) image formats in SVG were intrinsically rectangular. Perhaps I'm imagining though. Cheers D
Re: [whatwg] Proposal: navigator.cores
On Mon, 5 May 2014, Kenneth Russell wrote: It would be great to design a new parallelism architecture for the web, but from a practical standpoint, no progress has been made in this area for a number of years, and web developers are hampered today by the absence of this information. On Monday, May 05, 2014 7:46 PM Ian Hickson replied: Progress can be made imminently. Just tell me what you need. There's no reason this has to take a long time. The only reason it isn't in the spec already is that it hasn't been requested -- as far as I'm aware, until the past week, the last person who mentioned it on the list was me, several years ago. If multiple vendors are interested in a more elaborate solution that doesn't expose more fingerprinting bits, we can do that right away. What would be most helpful to do that is detailed descriptions of use cases, common pitfalls, experience with existing systems like Apple's GCD, strawman API proposals, and criticisms thereof. It strikes me as though some liaison with Khronos.org might make sense: http://www.khronos.org/ There are already several score of major companies involved in the manufacture of silicon that have come together to develop specs for such things as WebGL and WebCL (Heterogeneous parallel computing in HTML5 web browsers). Regards David
Re: [whatwg] input type=number for year input
I think there are two interesting questions here: 1. What is a number? A magnitude, an ordinal value (obeying the transitive property), a rotational value (like day of year, degrees, day of week), an interval value, a nominal labeling (take the SS Stevens taxonomy and add rotational [1])? Addresses frequently, but moreso in cities than in rural areas [2] have the property that 123 Huaihai Zhong Road is geographically between 120 Huaihai Zhong Road and 130 Huaihai Zhong Road, hence obeying the transitive property when articulated into geography. 130 State Street SW 30 State Street SW 30 State Street NW 130 State Street NW, meaning that sign is written using notation other than the minus sign. Generally, in places with European cultural heritage, the divisibility of the number (by two) determines the side of street, though even in Europe there are some fun and remarkable differences [3]. Many times, as with the ordinal numbers (first, second and so forth) there is the assumption that the n-th president will have served during a time intermediate between the n-1st and n+1st president. That is, inferences, in the classical sense of the semantic web, may be drawn about many classes of entities considered to be numeric. Do all things for which a simple bijection between the elements of a set and the integers, inherit the number property of that bijection, or simply if the bijection is humanly intuitive (though the cardinality of the rationals is aleph null, we might not expect the standard Cantor labeling to convey the ordinality to such). It is reminiscent of work with the gravitational flavorings of graphs [4] in which we ponder the question of how simple graphs like the internet might be flavored with a single dimension of artificial gravity so as to guide simplified navigation. 2. What sort of interface is best used to elicit a numerical response from a person? We often assume that the human will type such a thing, though for small n, radios and even selects work okay. Can a widget be developed called a throttle which allows the user to use a joystick to accelerate through an ordinal collection of n ordinal values (for large n1) and to pick a number more quickly using the throttle than by using the keyboard? Since the words of an alphabetic language have a natural ordering (imposed by alphabetization) are not words numeric, and cannot a throttle be used more effectively than a keyboard? Cheers David [1] http://en.wikipedia.org/wiki/Level_of_measurement [2] http://bitboost.com/ref/international-address-formats/prc-china/ [3] http://en.wikipedia.org/wiki/House_numbering [4] http://www.graphicalweb.org/2012/#presentation_19 -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nils Dagsson Moskopp Sent: Saturday, March 08, 2014 1:25 AM To: Jonathan Watt; whatwg Subject: Re: [whatwg] input type=number for year input Jonathan Watt jw...@jwatt.org writes: is it wrong to use input type=number for year input. I am certainly not an expert on the topic, but I believe the conceptual problem can be reduced to using an input designed for a group (in the mathematical sensce) to represent a value that is torsor. Quote http://ro-che.info/articles/2013-01-08-torsors.html: While adding two dates is not possible, it is possible to add a time interval to a date («five days from today»). This suggests that we should not confound dates and time intervals — they are different types of values. Therefore asking for a duration using input type=number is fine – asking for a calendar year, however, is obviously a type error. http://math.ucr.edu/home/baez/torsors.html -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] input type=number for year input
On Tuesday, February 18, 2014 8:24 PM Karl Dubost wrote Le 19 févr. 2014 à 08:17, Ian Hickson i...@hixie.ch a écrit : 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 In English. The same page you used: 西暦1年問題 Problema del año 1 Y10K 1년 문제 Проблема 1 года Проблема 1 року 1年问题 For example, the comma in France is used for 10,5 as in 10.5 (21/2). And the space is used as a separator 11 222 333,44 A good source for different conventions depending on the locales. http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_concernant_les_nombres http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers http://de.wikipedia.org/wiki/Wikipedia:Schreibweise_von_Zahlen http://zh.wikipedia.org/wiki/Wikipedia:%E6%A0%BC%E5%BC%8F%E6%89%8B%E5%86%8C/%E6%97%A5%E6%9C%9F%E5%92%8C%E6%95%B0%E5%AD%97 etc. I wonder if it would not be more flexible to have a `format` attribute. input type=number format=%Y/ (or any other formatting syntax) -- What fun! Thanks to jwatt for raising the issue and to Karl for casting it in the context that I presume jwatt was intending it to be cast. It reminds me of the early discussions, circa 2007 on whatwg/public-html, of what exactly was meant by 'semantics'. Is it merely HTML or is it meaning? In a cross-cultural sense, do we really expect that p and aside and quote and grid and section and all the other things (that HTML5.555... might ultimately asymptote with itself to include) are inclusive of the ways that cultures, the world wide, might choose to partition their discourse, into tags, elements, and taxonomies, replete with meaning, context, style and behavior? Perhaps at the core of human expression is the idea and until we respect one another for that core expression, distinctions between semantics, behavior, presentation and context are askew, or at least un-worldwidish. HTML7 should be radically different than HTML5: a new prime number requires new thinking and new participation and perhaps, even, reinvention at the expense of a broken wheel or two. Cheers David
Re: [whatwg] input type=number for year input
input [magnitude|quantity|quality|time|thing|person|place|action|epistemic|quantif ier|URI|anaphora|mediatype|direction|influence|...]=attribute-value-expressi on-with-micro-syntax with all appropriate cross-cultural studies underlying each attribute-value. I am reminded of the Navajo verb system, in which epistemic values (certainty), influence (transitive/intransitive), deixis (this/that/yonder), and quantifiers (unique, none, all, some) are not strictly orthogonal. Nle`i dzilh bits'i`i d'shighan : the unique and well-known hill over yonder, beyond it there is my house. Were the hill or the direction not well known, then it might be expressed differently (as I seem to recall). It's maybe a bad example since bits'i`i could be viewed as a preposition, but heck, it's been decades since I had a Navajo-speaking hitchhiker in my car (and we seemed never to agree on etymology)! What sorts of things might people want to say to us as web-folk? Are not those all the possible types of input? Cheers D -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Michael[tm] Smith Sent: Tuesday, February 18, 2014 7:31 PM To: Ian Hickson Cc: whatwg; Jonathan Watt Subject: Re: [whatwg] input type=number for year input -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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). --Mike - -- Michael[tm] Smith http://people.w3.org/mike -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTA/tCAAoJEIfRdHe8OkuV2aAP/iRM71IfqZtGq4RojC9iPBEe rBCMCd7X0JfqCibx+FIhXtaXoLwyqzK6ALM0I9XxHKzXhi1Ioqg67mLNif+ch8vu UNwwE/NYbjHkymspxg0N0IOQjTPcwDpra7avDjqmtzVsJImqe2nwEmKr9lfhl+NS GCu+U2f2Uoh5UTw10RAscRbODZoqbWcNboI7wGNXeavzckcaVvj7ePN9mjTty96N OmB2E+lgrlrrQXdHM2Vp5cuduPxoXUaEzOxEUc8la7P50/zgP+HW9Ultx0WC1g/3 5a1gpiuXteEdiCYbOz1sjP/XiCTMGNnUUFlWsSt8Rd/NC5tTbpM85vJsXabeLWnm 1Od4NhPHvcUAeHO+J+DtfmSDYB9G09NMAlMzFvhZyIxXlFGxGAvk5SRufvzzzk1B r9tTSFRiDsFyLIu9ILfe0ssXLpyrrq/0qV+QwAyebpBWSvewBnbEdeV5b3l4xVhc HKY9CU0/YOaJrmJ6gSVI1BB7wDE1Hpo7OwAXsAXIW7NrlLGNCj/d/ycJlBClIfrf T4ZoPxWnO2ijvp8niENZmbvU3SnNWiduWygZtwzlOUw2fNqHrR4g/PW+oo9d/qhN j97LOXwkFVM8cw4SjLaLctOxkgine96xQR8q38rwdLQ6PCmk4Bq5U12w9NkSAemR envZdVX/S7hoY3DrDzCW =gY28 -END PGP SIGNATURE-
[whatwg] related subject -- access to local files RE: Forms: input type=file and directory tree picking
A few years ago, probably on www-html5, I remember posing a question about enabling the once-unbroken ability to allow JavaScript with user-consent, to insert an image file (as the src of an img into a web page, viewed in the browser). It all used to be easy and worked in the two relevant browsers at the time: Netscape and IE. Then someone decided it was a security risk and that it preserved the privacy of the end user more to force him or her to upload the image to the server, create a round-trip from server to client and thence to be able to view a local image in a local web page. The old functionality continued to work in Netscape until its demise, and in IE until maybe version 6. The other browsers viewed the security risk as too high and ultimately IE seems to have agreed, hence breaking previous functionality. Of course, this seems just like what evil empires might define as security: forcing someone to upload all their stuff to a 'cloud' where always virtuous entities can protect us! I was most encouraged to hear that in some years forward from that time, we might actually regain the functionality we enjoyed in the early part of the previous decade! Anyhow, as I recall, at the time, Hixie commented and someone else chimed in with details (that seemed rather convoluted at the time) saying that it was something people were working on. Has this effort led to fruition? It has always seemed part and parcel to my concept of web applications and until the Design Principles including Don't Break the Web came along, it seemed to work quite well. Apologies if this is not the right place to ask questions about web functionality. The HTML/CSS/forms/whatwg/W3C nomenclature and jurisdictional issues are something that I haven't been quite able to follow with the attention that it would seem to require. Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jonas Sicking Sent: Wednesday, October 02, 2013 4:36 PM To: Glenn Maynard Cc: WHAT Working Group; Jonathan Watt; Ian Hickson Subject: Re: [whatwg] Forms: input type=file and directory tree picking On Wed, Oct 2, 2013 at 11:52 AM, Glenn Maynard gl...@zewt.org wrote: On Wed, Oct 2, 2013 at 1:02 PM, Jonas Sicking jo...@sicking.cc wrote: That's not the only alternative. For example, a third alternative is that the user's selection (e.g. a directory) is returned quickly, not pre-expanded, and then any uploading happens in the background with the author script doing the walk and uploading the files. It's unclear to me what you are proposing here. Can you elaborate? The same thing I did, I think: an API to navigate the directory tree as needed, and to never greedily recursing the directory tree. Unfortunately that's forbidden by current specs. Or rather, the only implementation strategy that I can see for doing that while implementing the current spec would require synchronously traversing the full directory tree whenever element.files is accessed. At least to me that would have performance issues that are unacceptable to Firefox. Though of course you or anyone else is free to propose changes to the spec to improve that situation. / Jonas
Re: [whatwg] Clipping text in in canvas
Last I checked applying a clipPath to text in SVG works consistently across browsers, and there it remains accessible: to screen readers, indexing, searching, drag-to-select, etc. Why would one want a bunch of pixels that resemble text? Just saying, David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jasper St. Pierre Sent: Sunday, September 15, 2013 11:38 AM To: wha...@whatwg.org Subject: [whatwg] Clipping text in in canvas The canvas specification maintains: These shapes are painted without affecting the current path, and are subject to shadow effects, global alpha, the clipping region, and global composition operators. [0] But no browsers I tested actually implement the clipping region part. Should this be removed for backwards compatibility reasons? Should we introduce a new method of clipping text be introduced, or should we just require users who want to draw clipped text to draw to a scratch canvas and use drawImage to copy the pixels? [0] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-eleme nt.html#drawing-text-to-the-bitmap -- Jasper
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
Hi Rik, Just affirming what you've said in SVG: http://cs.sru.edu/~ddailey/svg/edgeblurs.svg The middle rects are crisp, having been merely translated leftward and downward by half a pixel. Zooming in from the browser rectifies the problem (as expected) after a single tick. I remember folks discussing sub-pixel antialiasing quite a bit on the SVG lists circa fall/winter 2011. It seemed to cause some troubles for D3. Is that the same issue? Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rik Cabanier Sent: Tuesday, July 23, 2013 7:19 PM To: wha...@whatwg.org Subject: [whatwg] Blurry lines in 2D Canvas (and SVG) All, we've noticed that if you draw lines in canvas or SVG, they always end up blurry. For instance see this fiddle: http://jsfiddle.net/V92Gn/128/ This happens because you offset 1 pixel and then draw a half pixel stroke on each side. Since it covers only half the pixel, the color gets mapped to 50% gray. You can work around this by doing an extra offset of half the devicepixelratio, but ideally this should never happen. Is this behavior specified somewhere? Is there a way to turn this off?
Re: [whatwg] Blurry lines in 2D Canvas (and SVG)
Seeing what Kornel wrote about a solution to the problem for canvas, makes persuasive support, to me, for Glenn Maynard's argument that [concerning SVG and canvas] I think they should be two separate discussions. One of the intentions (at least historically) of SVG is to allow declarative rather than scripted solutions. As I read this conversation from a declarative perspective (trying to transcode script into markup) I am seeing a dozen little flag-attributes that all interact with one another in a grand logical hyperplane. Sorry, for what might be a flawed metaphor, but I've been stuck in a logical hyperplane for the past few days and I am cursing it! Cheers D (Lie algebra is even worse than Lie geometry! -- https://en.wikipedia.org/wiki/Sophus_Lie ) -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Kornel Lesinski Sent: Tuesday, July 23, 2013 10:09 PM To: Rik Cabanier Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] Blurry lines in 2D Canvas (and SVG) On Wed, 24 Jul 2013 02:13:19 +0100, Rik Cabanier caban...@gmail.com wrote: It's not intuitive. It's a pretty common pitfall, but it's logical. For 1-pixel lines it could be fixed by allowing authors to specify that path should be stroked with lines aligned to inside/outside of the path (which is a useful feature on its own). Sure, but how can we fix this? It's not very intuitive that I have to keep track of the devicePixelRatio (and the current CTM?) to get crisp lines. To what extent does it need to be fixed? Manually snapping lines to canvas pixels isn't too hard, e.g. subtracting 0.5 from x/y and adding 1 to width/height to get pixel-aligned rectangle outside the box. It does get trickier with transforms indeed :( Is it enough to snap to canvas pixels? (future of HD canvas is uncertain, so authors may need to resize canvas to match devicePixelRatio anyway). Is it enough if there was strokeOutside()/strokeInside() that makes untransformed lines pixel-aligned? Or is it necessary to have snapping for odd-width lines that are stroked centered on a path? Do authors expect lines in canvas with non-integer transforms to be crisp? Should arc() and bezier curves also be snapped? What if you want a line that touches the curve? What we need is that artwork 'snaps' to the native pixels while still being antialiased. How should snapping be done? If fill() of a 2x2 rect draws: XX XX how would stroke() look like? .XX. .XX. or .. .. or ... .X. ... If you have path that is 2.5 device pixels wide, is it going to be snapped to different width depending whether you draw it at (0, 0) or (0.1, 0)? Would that also make circles ellipses? Snapping makes animated slow movement choppy, so authors may also want ability to disable it for selected paths/drawing operations or even for each axis separately (e.g. to smoothly animate horizontal movement while object is snapped to pixels vertically, etc.) -- regards, Kornel
Re: [whatwg] 2D canvas feature proposal: text decoration
You know, I'm not quite sure why we have text in canvas at all. It's not really text you know -- it's just a bunch of pixels. You can't select it, you can't copy it to the clipboard, it's not accessible without a bunch of effort that authors generally don't use. It's generally illegal in most civilized places. Why not use SVG? It's got text decoration. Text is text. It's just that the more conspiratorial and selfish of the browser vendors back when things were being voted on seemed to push canvas since they already owned it and SVG seemed hard and like they might have to learn something by way of graphics in their corporate portfolios. That's how I see it, anyhow. WHATWG doesn't vote, of course. Cheers DD -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Justin Novosad Sent: Thursday, April 18, 2013 3:59 PM To: WHAT Working Group Subject: [whatwg] 2D canvas feature proposal: text decoration This is a really simple proposal to add support for text decorations in 2D canvas contexts. IDL to add to interface CanvasDrawingStyles: attribute DOMString textDecoration; It would support all the same modes as the 'text-decoration' CSS property (except inherit), and default would be 'none'. What say y'all?
Re: [whatwg] Submitting contentEditable Content In A Form -- also in SVG and audio contexts
I don't know if this matters or not, but at some point in time, other standards than HTML like svg or audio might receive sensible proposals to allow other media (than just text) to be contentEditable. Just as it makes sense to have built in text editors (imagine the spectrum ranging from textarea to rich web content editors like in Google+ and beyond) in a spec that deals with text (as in HyperText ML handling such routine things as word-wrap, backspace, delete, select, copy, paste etc.), so might it make sense to have a default (cross-browser-consistent) generic drawing pad that produces structured graphical objects (and not just silly pixelbits) built into a graphical element or a default (cross-browser-consistent) sound studio built into audio objects. The GUI interfaces for these things have been pretty consistent since MacDraw in 1984 and SoundEdit in 1986 so any patents with the oft-replicated interface would have expired by now. I'm not saying that coherent proposals that meet the acceptance of the standards community for such will emerge in the next few years, but at some time, the logic for them is likely to eventually overcome the resistance. And, in the meantime, it might make sense to make sure that what is done with the stuff in HTML is consistent with the broader spectrum of possible use cases that will emerge in the future. Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian Hickson Sent: Wednesday, October 17, 2012 7:24 PM To: whatwg Cc: a...@aryeh.name Subject: Re: [whatwg] Submitting contentEditable Content In A Form On Fri, 7 Sep 2012, Hugh Guiney wrote: I'm developing a CMS and would like to be able to submit user-edited content back to the server, but at present, it's not possible to do this without copying the contents of the edited element with JavaScript into, say, a hidden form field. I think that there should be some mechanism to associate contentEditable elements with forms maybe the combination of contentEditable=true and the presence of @name creates an implicit form control? The value sent to the server could be equivalent to that element's innerHTML. Thoughts? I haven't added this, because contenteditable= is only truly useful with scripting enabled, and it's basically one line of script to support shunting the current value into a hidden input. This becomes especially more relevant when contenteditable is used for editors that don't just upload HTML; for example, the Google+ editor is contenteditable= but it's not going to upload the HTML, it uploads structured data. Incidentally, it seems to use a WebKit-specific plaintext-only value. Should we spec that? Aryeh? It's filed as: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14554 If this should involve changes to HTML, let me know. On Fri, 7 Sep 2012, Mikko Rantalainen wrote: The contenteditable attribute is meant for low level wysiwyg-editor like behavior framework and it is not meant to work standalone without scripting. Indeed. I'd suggest supporting textarea type=text/html with a built-in HTML wysiwyg editor if any UA wants to support HTML editing without JavaScript. In that case, the UA should provide a scriptable method for detecting for native support of type=text/html. As a result, a CMS system could fallback to e.g. TinyMCE or CKeditor to emulate the missing support. This is actually what old versions of IE did (as htmlarea, IIRC), but it was dropped. I don't fully understand why, but I'm skeptical of introducing a new control for this without making sure we don't make the same mistakes, which means figuring out what those mistakes were. On Thu, 13 Sep 2012, Ojan Vafai wrote: I think this is a problem that we need to address more generally. I'm not sure what the API should look like, but it's not specific to contentEditable. I should be able to make a Web Component that submits specific values with forms based off it's content. If we solve that problem right, it'll be possible to make contentEditable elements submit with forms without extra JS code. Given how easy it is to copy data into a hidden input, why isn't that sufficient? It would actually be pretty difficult to come up with an API that is simpler than declaring an input and settings its value... On Sun, 16 Sep 2012, Jonas Sicking wrote: I agree, I would like to see a more general-purpose solution for this. One problem that we have is that |new FormData(form)| allows synchronously grabbing, so we'd likely end up having to fire synchronous callbacks, which is always unfortunate, but I don't see an alternative here. Especially since grabbing data asynchronously is always risky. This is something else that just already works with input type=hidden. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A
Re: [whatwg] Submitting contentEditable Content In A Form -- also in SVG and audio contexts
No I had nothing at all in mind that might be inconsistent with what is being discussed -- just sort of a free association I suppose. Cheers David -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Wednesday, October 17, 2012 9:27 PM To: David Dailey Cc: 'whatwg'; a...@aryeh.name Subject: RE: [whatwg] Submitting contentEditable Content In A Form -- also in SVG and audio contexts On Wed, 17 Oct 2012, David Dailey wrote: I don't know if this matters or not, but at some point in time, other standards than HTML like svg or audio might receive sensible proposals to allow other media (than just text) to be contentEditable. Just as it makes sense to have built in text editors (imagine the spectrum ranging from textarea to rich web content editors like in Google+ and beyond) in a spec that deals with text (as in HyperText ML handling such routine things as word-wrap, backspace, delete, select, copy, paste etc.), so might it make sense to have a default (cross-browser-consistent) generic drawing pad that produces structured graphical objects (and not just silly pixelbits) built into a graphical element or a default (cross-browser-consistent) sound studio built into audio objects. The GUI interfaces for these things have been pretty consistent since MacDraw in 1984 and SoundEdit in 1986 so any patents with the oft-replicated interface would have expired by now. I'm not saying that coherent proposals that meet the acceptance of the standards community for such will emerge in the next few years, but at some time, the logic for them is likely to eventually overcome the resistance. And, in the meantime, it might make sense to make sure that what is done with the stuff in HTML is consistent with the broader spectrum of possible use cases that will emerge in the future. That seems reasonable in general. Did you have anything specific in mind that isn't consistent in this way? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] gradient edge case
While on the topic, it seems like reflected linear gradients would be quite handy -- insert an edge into the stop-sequence and then reflect or repeat from there. Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rik Cabanier Sent: Saturday, September 01, 2012 9:59 PM To: whatwg; public-canvas-...@w3.org Subject: [whatwg] gradient edge case All, Currently the canvas spec specifies the following: If x0 = x1 and y0 = y1, then the linear gradient must paint nothing. and If x0 = x1 and y0 = y1 and r0 = r1, then the radial gradient must paint nothing Why is this? It seems that the gradient should just be a line or circle that has the first colorstop's on the left/inside and the last colorstop's color on the right/outside. Rik
Re: [whatwg] Canvas roundedRect
It seems to me that the primary use of rounded rectangles is for UI's rather than art, and as such, SVG, that supports DOM and events, already has syntax for rounded rectangles. I have seen how the canvas folks like to re-invent wheels, but the path syntax within canvas already should allow creation of line arc line arc sequences, and making things too easy would not appeal to the canvas machismo would it? How many rounded rectangles have you ever seen that don't invite mouseclicks? And then do you really want to try to calculate whether or not the mouse event is atop one of those thingies, particularly after it has been rotated, scaled and skewed? I'm just not seeing why canvas would need this. Regards David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Igor Trindade Oliveira Sent: Thursday, June 21, 2012 12:59 PM To: whatwg@lists.whatwg.org Subject: [whatwg] Canvas roundedRect Currently, canvas2d does not have support for rounded rectangles and the web developers are implementing rounded rectangles using arcs or bezier curves.[1][2] So i propose the addition of two new functions: void fillRoundedRect(unrestricted double x, unrestricted double y, unrestricted double w, unrestricted double h, unrestricted double xRadius, unrestricted double yRadius); void strokeRoundedRect(unrestricted double x, unrestricted double y, unrestricted double w, unrestricted double h, unrestricted double xRadius, unrestricted double yRadius); Where the xRadius and yRadius arguments specify the radii of the ellipses defining the corners of the rounded rectangle. Additionally, if we know that the path is a rounded rectangle, we can make optimizations in the graphics libraries reducing the amount of tesselations. [1] http://www.scriptol.com/html5/canvas/rounded-rectangle.php [2] http://www.supercalifrigginawesome.com/Extending-Canvas-to-Draw-Rounded-Rect angles
Re: [whatwg] was The pic element, now about alt text
On Monday, June 04, 2012 1:30 PM David Singer wrote This may be an aside to the current discussion, but actually I think that user-presentable text should *never* be in an attribute. Why? 1) 'ML' stands for markup language; what's in the markup should be information about the content, not the content itself. 2) More important, when text is in an attribute, it's not amenable to markup. You want to style the alt text, or associate it with a CSS class, or tag it with a language, script, or writing direction, or.? It needs to be in the content, and then that's all possible. I realize that changing where alt text is for existing elements would be.problematic.but I don't think we should propagate the error further. - This thinking seems very valid to me. By extension, when the semantics of the language is geometry, as in SVG, then relegating that content to CSS rather than the DOM would be even a tad worse than injecting it into attributes. Actual nodes seem to be where the meaningful nouns of a language should be with attributes being for adjectives and styles for adverbs. The verbs are, by this metaphor, behaviors as revealed through script or declarative constructs. Cheers DD
Re: [whatwg] Adding blending to the canvas API
Rik wrote: Not having an implementation of BackgroundImage makes blending in SVG very difficult. I'm unsure why you think that specifying a magenta color will change the color model to subtractive. As far as I know, the renderer is always computing in RGB. No I don't think that the color model in the browser changes. Rather the Venn diagrams as drawn using mode=screen vs mode=multiply depict (in the proper browser) the traditional diagrams of those models. http://cs.sru.edu/~ddailey/svg/V9.svg as viewed in Opera corresponds to those diagrams usually hand-painted in texts (or broken in to separate paths in Wikipedia at http://en.wikipedia.org/wiki/Subtractive_color -- hence undermining accessibility). Cheers David
Re: [whatwg] Adding blending to the canvas API
Perhaps if some of the browsers start to implement blend modes for disposable graphics they'll finally start to do it properly for SVG as well. I've had a devil of a time figuring out if Opera or IE/ASV properly handles some of the effects at http://cs.sru.edu/~ddailey/svg/V9.svg since none of the other browsers are brave enough to try it. The first two diagrams should display, respectively, additive and subtractive color, while some of the others experiment with more intuitive color models using feImage to find region intersections and or simple opacity. Humans, without training tend not to thing R+G=Y (additive) or even that B+Y=G (subtractive), in part because tetrachromacy in the visual cortex seems to override whatever trichromacy we have at the retinal level (varies by gender, btw). Also methodologies that estimate color differences on the basis of JND's (such as the CIE work in Rochester in the 1930') may not generalize well to distances that are further across the perceptual space, methinks. Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rik Cabanier Sent: Friday, April 13, 2012 1:49 PM To: David Geary Cc: Jeremy Apthorp; Ashley Gullen; wha...@whatwg.org Subject: Re: [whatwg] Adding blending to the canvas API On Fri, Apr 13, 2012 at 10:36 AM, David Geary david.mark.ge...@gmail.comwrote: On Fri, Apr 13, 2012 at 11:16 AM, Rik Cabanier caban...@gmail.com wrote: On Fri, Apr 13, 2012 at 2:17 AM, Ashley Gullen ash...@scirra.com wrote: This looks very handy for games as well! Things like 'screen' work very nicely for some effects, especially explosions. Yes, these effects are very commonly used in games, animation and artwork. And presumably having them implemented by browser vendors will be more efficient than doing it by hand. Correct. I've found a case where someone implemented this themselves and it is very slow so it's not useful if you want to create an animation or a game. Surely you'd want to extend the existing list of globalCompositeOperation though? That seemed the easiest way to go. I can see some edge cases that you wouldn't be able to implement easy (ie do a src-out with a screen). I think it would still be possible to do but it would take an extra step. And presumably the extra step will be less efficient than if the browser did it. Also, the developer must implement the extra step. It seems to me that the extra step may also require an additional offscreen bitmap. Correct. The question is if you want to extend the API if the feature is not that common. Otherwise you'd have to define how globalCompositeOperation and globalBlendOperation interact. My spec is trying to define how they interact. Basically, blending is done first and replaces the original source. This new source is then composited. Sorry, I'm confused. If that's how they interact, then musn't blending and compositing be separate things? If you extend the list of globalCompositeOperation valid values to include blends, then you can do either a blend or a composite, but not both. Specifying a blend mode would imply doing a src-over with the result of the blend. Every authoring application (not just Adobe's) that I know of, implements it that way. Thanks for the feedback! Rik On 12 April 2012 00:39, Rik Cabanier caban...@gmail.com wrote: :-) They are definitely more familiar to designers but they both have their place. On Wed, Apr 11, 2012 at 4:30 PM, Jeremy Apthorp jere...@chromium.org wrote: On Wed, Apr 11, 2012 at 4:05 PM, Rik Cabanier caban...@gmail.com wrote: All, I'm working on a spec to add blending and compositing through simple CSS keywords. It is trying to define a generic model that is not specific to Canvas, HTML or SVG and then lists how the model could be implemented. We've gotten some comments that this feature would be useful in Canvas as well so I was wondering if it made sense to add it to the canvas API. I can see 2 ways of adding this: 1. extend the list of compositing operators ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canva s-element.html#compositing ) with blending. This is what is currently in the draft spec ( https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.htmlchapter 7) 2. create a new attribute on the context called 'globalBlendOperation' that takes the same list of blend operations as css ( https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blend- mode ) Any thoughts? This seems much more useful than the existing composite operations :)
Re: [whatwg] CSS Filter Effects for Canvas 2D Context
Of course if we go back enough years, there was a recommendation that foreign object be implemented across browsers so that any HTML content could be filtered with the power of SVG (including the relatively lightweight canvas). I think people worried that HTML would become obsolete then. Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Chris Marrin Sent: Tuesday, January 24, 2012 7:23 PM To: Ronald Jett Cc: wha...@whatwg.org Subject: Re: [whatwg] CSS Filter Effects for Canvas 2D Context On Jan 24, 2012, at 11:56 AM, Ronald Jett wrote: Hello, I think that bringing the new CSS filters (http://html5-demos.appspot.com/static/css/filters/index.html) to canvas might be a good idea. Some of the new filters, specifically blur, would definitely speed up some applications. I saw that there was a previous discussion on this list about bringing SVG filters to canvas, but it was a few years back and it doesn't seem like the discussion yielded much. It would be great if you could turn the filters on and off while drawing. Something like: ctx.blur(20); // turns on a 20px blur ctx.drawRect(0, 0, 50, 50); // this will be blurred ctx.blur(0); // turns off blur ctx.drawRect(100, 100, 50, 50); // this will not be blurred You could even do multiples: ctx.blur(2); ctx.sepia(1); ctx.drawImage(img, 0, 0); ctx.endFilters(); // turn all filters off Another benefit of having these effects in canvas is that we could utilize toDataURL to save out an image that a user/application has filtered. Thoughts? You can apply CSS Filters to a Canvas element. Maybe it would be better to put the items you want filtered into a separate canvas element and use CSS Filters on that? The big advantage of doing it that way is that the CSS filters can be animated and hardware accelerated. Adding filter functions to canvas would require you to re-render the items for every filter change and you'd have to animate it all yourself. Generally, I think that often a hybrid approach to Canvas, where you draw into multiple Canvas elements and use CSS transforms, animations (and now filters) for positioning and effects can give you the best of both worlds... - ~Chris cmar...@apple.com
[whatwg] How to render typographic puns in HTML5 -- aside, legend, alt, other?
I know that there are a variety of accessibility things in HTML5. Take a look at this small collection of simple typographic puns, currently rendered in SVG: http://cs.sru.edu/~ddailey/svg/2011/simplePuns.svg I've added title and desc to these in a way to explain the sometimes visual effects to audiences that might not be reached by ordinary assistive technology. The use of the mouse or examination of the source should reveal what I'm up to. Question: how would you folks advise doing this in HTML5. Legend was the thing that came to mind, but it looks as though it's not usable everywhere. Aside seems to have slightly different semantics, since it is not so much an aside as an explanation. Maybe this is where a micro-format is appropriate? regards David
Re: [whatwg] href synonyms?
There are likewise annoying things in SVG. xlink:href=#Q , attributeName=url(#Q) etc. Every time I go to use a gradient, a pattern, a use, a filter, a clipPath, or a mask, I have to look up, in the manual, which notation happens to be used for this particular thing. I'm sure there may have been historic logic, but the pain for the developer results in lost productivity. Agreed that developers would still need to know an antiquated illogic, but over time, wouldn't the world become a better place? 400 hours of implementers' time now is probably hard to justify, perhaps, given that the return on this investment would come in zillions of developers' microseconds harvested over years. Cheers David -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian Hickson Sent: Thursday, April 28, 2011 3:45 PM To: Roger Hågensen; Nils Dagsson Moskopp; Aryeh Gregor Cc: whatwg@lists.whatwg.org Subject: Re: [whatwg] href synonyms? On Thu, 9 Dec 2010, Roger H�gensen wrote: This has irked me lately... * a uses /href/ (outbound) * link uses /href/ (inbound and outbound) * img uses /src/ (inbound) * iframe uses /src/ (inbound) * script uses /src/ (inbound) * embed uses /src/ (inbound) * object uses /data/ (inbound) * applet uses /code/ (inbound) * css @import (inbound) * I'm sure I missed some more that should be listed here too. It seems like in all cases these are simply a URI, and whether it takes you to some place or if it loads in something is purely contextual. So why not spec all those to simply be synonyms for href (which is used both for inbound and outbound). Because that would add extra complexity to browsers and the spec without really simplifying the language much (since authors would still have to know about the synonyms to be able to edit older pages or pages written by other people). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] How to handle multitrack media resources in HTML
Silvia Pfeiffer and Ian Hickson exchanged: Yes, and the same (lack of definition) goes for javascript manipulation. It'd be great if we had the tools for manipulating video and audio tracks (extract/insert frames, move audio snippets around). It would make A/V editing - or more creative uses - really easy in HTML5. That's a use case we should investigate in due course, but I think it's probably a bit early to go there. When we do get around to it, it would be nice, as well, to be able to create sounds (as from wave forms) from scratch, in the browser. Cheers David
