Re: [whatwg] Knuth and Plass algorithm; boxes & glue & penalties

[David Dailey]

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 , 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

[David Dailey]

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  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  support to allow pointing to these kinds of files.  They'd need 
some sort of native controls on the  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  formats (and perhaps 
by extension)  formats in SVG were intrinsically rectangular. Perhaps 
I'm imagining though.

Cheers
D

Re: [whatwg] Proposal: navigator.cores

[David Dailey]

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] for year input

[David Dailey]

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 n>1) 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]  for year input

Jonathan Watt  writes:

> is it wrong to use  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 :

> 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  is fine – asking for 
a calendar year, however, is obviously a type error.




--
Nils Dagsson Moskopp // erlehmann

Re: [whatwg] for year input

[David Dailey]

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]  for year input

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ian Hickson , 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-

Re: [whatwg] for year input

[David Dailey]

On Tuesday, February 18, 2014 8:24 PM
Karl Dubost wrote

Le 19 févr. 2014 à 08:17, Ian Hickson  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.


(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  and  and  
and  and  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  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

[whatwg] related subject -- access to local files RE: Forms: and directory tree picking

[David Dailey]

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  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:  and directory tree picking

On Wed, Oct 2, 2013 at 11:52 AM, Glenn Maynard  wrote:
> On Wed, Oct 2, 2013 at 1:02 PM, Jonas Sicking  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

[David Dailey]

I'm sure there are such uses and I'm assured that you have one. I was just
sending out my canned reminder that alternatives to canvas exist (many folks
seemed not to know that, only a few years ago).

 

Cheers and regards

D

 

From: magc...@gmail.com [mailto:magc...@gmail.com] On Behalf Of Jasper St.
Pierre
Sent: Sunday, September 15, 2013 12:09 PM
To: David Dailey
Cc: wha...@whatwg.org
Subject: Re: [whatwg] Clipping text in in canvas

 

 

On Sun, Sep 15, 2013 at 12:04 PM, David Dailey 
wrote:

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

 

I have an insane, complex use case, and you'd laugh at me if I told you what
it was, but trust me when I say I need an immediate mode drawing API like
 instead of a retained scene graph like SVG.

-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
<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-elem
ent.html#drawing-text-to-the-bitmap> 
nt.html#drawing-text-to-the-bitmap

--
  Jasper






-- 
  Jasper

Re: [whatwg] Clipping text in in canvas

[David Dailey]

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)

[David Dailey]

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 
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] Blurry lines in 2D Canvas (and SVG)

[David Dailey]

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] 2D canvas feature proposal: text decoration

[David Dailey]

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

[David Dailey]

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  or  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  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] Submitting contentEditable Content In A Form -- also in SVG and audio contexts

[David Dailey]

I don't know if this matters or not, but at some point in time, other standards 
than HTML like  or  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  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  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 , 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 , why isn't that 
sufficient? It would actually be pretty difficult to come up with an API that 
is simpler than declaring an  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 .

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.

Re: [whatwg] gradient edge case

[David Dailey]

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

[David Dailey]

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  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  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  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 element, now about alt text

[David Dailey]

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

[David Dailey]

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

[David Dailey]

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
wrote:

> On Fri, Apr 13, 2012 at 11:16 AM, Rik Cabanier  wrote:
>
>> On Fri, Apr 13, 2012 at 2:17 AM, Ashley Gullen  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  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 
>> >> > >> >wrote:
>> >>
>> >> > On Wed, Apr 11, 2012 at 4:05 PM, Rik Cabanier 
>> >> > 
>> >> 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 

Re: [whatwg] CSS Filter Effects for Canvas 2D Context

[David Dailey]

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?

[David Dailey]

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  and  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] Web Forms 2 Repetition Model-please reinstate on specification

[David Dailey]

Hi folks, 

I've written lots of forms like the ones in the example provided (with
expanding controls for what could be considered repeating values as in
database apps). I see it as another possible use case for  .

See http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm
(look also at the paper as well as the examples)

So now we have three proposed domains for applicability of : web
forms. svg, and inkml.

On the other hand, I was one of those who thought  might apply to
domains outside SVG.

Cheers
David



-Original Message-
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ian Hickson
Sent: Monday, September 19, 2011 7:03 PM
To: wha...@aaabit.com
Cc: wha...@whatwg.org
Subject: Re: [whatwg] Web Forms 2 Repetition Model-please reinstate on
specification

On Mon, 19 Sep 2011, wha...@aaabit.com wrote:
>
> Please reinstate this feature (Web Forms 2 / Repetition Model) on the 
> official specification.
> 
> My use-case/ justification is explained on this forum thread:
> 
> http://forums.whatwg.org/bb3/viewtopic.php?f=3&t=4717
> 
> I want a declarative solution for simple repetition (e.g. for scientific 
> data forms, for use in high-security institutions where Javascript may 
> be disabled); and the ability to write my own Javascript based solution 
> for anything else. (I can already do the latter, but the former eludes 
> me; most disappointingly considering that this feature was well designed 
> and close to being released).

We took it out because it was just far too complicated a solution to solve 
far too narrow a set of use cases.

However, there is a lot of ongoing work in this area of research, 
especially currently in the public-weba...@w3.org group. I encourage you 
to bring up the suggestion there. Unfortunately, coming up with a 
declarative solution whose cost-to-usefulness ratio is good enough has 
proven over the years to be a rather elusive goal.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] href synonyms?

[David Dailey]

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...
> 
>*  uses /href/ (outbound)
>*  uses /href/ (inbound and outbound)
>*  uses /src/ (inbound)
>*  uses /src/ (inbound)
>* 

Re: [whatwg] How to handle multitrack media resources in HTML

[David Dailey]

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