https://wiki.whatwg.org/api.php?action=feedcontributions&user=Sicking&feedformat=atomWHATWG Wiki - User contributions [en]2024-03-29T14:41:26ZUser contributionsMediaWiki 1.39.3https://wiki.whatwg.org/index.php?title=Meta_referrer&diff=9673Meta referrer2014-08-15T16:38:30Z<p>Sicking: /* Specification */</p>
<hr />
<div>==Overview==<br />
<br />
This document describes a proposal the "referrer" metadata name. Using the referrer metadata attribute, a document can control the behavior if the Referer HTTP header attached to requests that originate from the document.<br />
<br />
==Use Cases==<br />
<br />
An author might wish to control the <code>Referer</code> header omitted by a document for a number of reasons.<br />
<br />
===Privacy===<br />
<br />
A social networking site has a profile page for each of its users, and users add hyperlinks from their profile page to their favorite bands. The social networking site might not wish to leak the user's profile URL to the band web sites when other users follow those hyperlinks (because the profile URLs might reveal the identity of the owner of the profile).<br />
<br />
Some social networking sites, however, might wish to inform the band web sites that the links originated from the social networking site but not reveal which specific user's profile contained the links.<br />
<br />
===Security===<br />
<br />
A web application uses HTTPS and a URL-based session identifier. The web application might wish to link to HTTPS resources on other web sites without leaking the user's session identifier in the URL.<br />
<br />
===Trackback===<br />
<br />
A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive [http://en.wikipedia.org/wiki/Trackback trackback] links.<br />
<br />
===Object-Capability Discipline===<br />
<br />
Some web applications wish to follow an object-capability discipline. The <code>Referer</code> header constitutes an ambient authority, contrary to an object-capability discipline. Having the ability to disable the <code>Referer</code> header makes it easier for these web applications to follow this discipline.<br />
<br />
==Specification==<br />
<br />
Keyword: <code>referrer</code><br />
<br />
The referrer metadata attribute can have one of four values for its content attribute:<br />
* <code>never</code><br />
* <code>always</code><br />
* <code>origin</code><br />
* <code>default</code><br />
<br />
When a meta element is inserted into the document, if its name attribute is presents and matches the referrer metadata name, then the user agent must run the following algorithm:<br />
# If the meta element lacks a content attribute, abort these steps.<br />
# Let the document's ''referrer-policy'' be the value of the content attribute converted to lower case with leading and trailing <code>LWS</code> removed.<br />
# If the document's ''referrer-policy'' is not one of the strings listed above, replace the document's ''referrer-policy'' with the string <code>default</code>.<br />
<br />
''TODO:'' This algorithm causes the most recently added meta element to control the ''referrer-policy''. Should we support changing the policy by setting the content attribute?<br />
<br />
Replace Step 3 of ''Fetching resources'' in the HTML standard [[http://www.whatwg.org/specs/web-apps/current-work/ HTML]] with the following text:<br />
<blockquote><br />
Let the ''referrer-header-value'' be the document's ''current address of document''.<br />
<br />
Remove any <fragment> component from the ''referrer-header-value''.<br />
<br />
If the ''origin'' of the appropriate Document is not a scheme/host/port tuple, then replace the ''referrer-header-value'' with the empty string, regardless of its value.<br />
<br />
* If the ''referrer-policy'' is <code>never</code>:<br />
: Replace the ''referrer-header-value'' with the empty string, regardless of its value.<br />
<br />
* If the ''referrer-policy'' is <code>default</code>:<br />
: Replace the ''referrer-header-value'' with the empty string if the <scheme> component of the ''referrer-header-value'' represents a protocol that uses transport-layer security and the <scheme> component of the resource being fetched does not.<br />
<br />
* If the ''referrer-policy'' is <code>origin</code>:<br />
: Replace the ''referrer-header-value'' with the ''ASCII serialization'' [[http://tools.ietf.org/html/draft-ietf-websec-origin ORIGIN]] of the ''origin' of the appropriate Document.<br />
<br />
* If the ''referrer-policy'' is <code>always</code>:<br />
: Do not alter the ''referrer-header-value''. '''Note: This might cause https referrers to be sent over the network as part of unencrypted HTTP requests.'''<br />
</blockquote><br />
<br />
<br />
''Question:'' Do we need a <code>always-origin</code> value as well? As to permit websites to use the always policy while still just sending the origin? For example to enable https websites to send an origin to http websites.<br />
<br />
<br />
In Step 5 of ''Fetching resources'' in the HTML standard [[http://www.whatwg.org/specs/web-apps/current-work/ HTML]], replace the text "For the purposes of the Referer (sic) header, [...]" with the following text:<br />
<blockquote><br />
For the purposes of the Referer (sic) header, use the ''referrer-header-value'' are generated in Step 3.<br />
</blockquote><br />
<br />
''TODO:'' We want this policy to affect resource loads done by the speculative parser. I'm not sure the speculative parser is part of the spec's machinery, so we need to figure out how to specify its behavior... Perhaps in an implementation consideration section?<br />
<br />
==Examples==<br />
<br />
This meta element instructs the user agent to omit the <code>Referer</code> header in all HTTP requests that originate from the document containing the element:<br />
<pre><br />
<meta name="referrer" content="never"><br />
</pre><br />
<br />
This meta element instructs the user agent to include the document's origin in the <code>Referer</code> header rather than the full URL of the document:<br />
<pre><br />
<meta name="referrer" content="origin"><br />
</pre><br />
'''Note:''' The user agent will include the origin string in the <code>Referer</code> header even for links from HTTPS to HTTP resources.<br />
<br />
==Issues==<br />
<br />
How does this interact with rel=noreferrer? Presumably rel=noreferrer should override whatever global setting the user agent gets from the meta element.<br />
<br />
The origin is not a canonical URL as it lacks a path. The user agent should probably just add / as path.<br />
<br />
What should happen if the origin is unique? Presumably the referrer should be omitted in that case.<br />
<br />
[[Category:Proposals]]</div>Sickinghttps://wiki.whatwg.org/index.php?title=Canvas_Batch_drawImage&diff=9661Canvas Batch drawImage2014-08-04T19:53:08Z<p>Sicking: /* Suggested IDL */</p>
<hr />
<div>:Batching drawImage calls to achieve near-native performance for sprite/image based animations and games.<br />
<br />
== Use Case Description ==<br />
Many web applications and games use 2D Canvases and the drawImage method to bring sprites to screen. Often, a large number of calls to drawImage occur for each frame presented to screen.<br />
<br />
=== Current Limitations ===<br />
When calling drawImage hundreds or thousands of times per animation frame, API bindings overhead and internal bookkeeping costs associated with individual draw calls become a significant performance bottleneck, which prevents web applications from achieving near-native performance levels.<br />
<br />
=== Current Workaround ===<br />
With WebGL, batching sprite draws is possible thanks to vertex buffers. WebGL is not as broadly supported as 2D canvas, and is a considerably more complex solution to a problem that could otherwise be solved with a 2D canvas.<br />
<br />
=== Benefits ===<br />
<br />
Rendering Performance.<br />
<br />
=== Requests for this Feature ===<br />
<br />
* <cite>[https://groups.google.com/a/chromium.org/forum/#!topic/graphics-dev/RzHob5VS8Dg]</cite> <blockquote><p>On Nexus 7 device, it can reach 60fps for 1000 sprites drawing at the same time [referring to a native canvas implementation]. However, the fps is very poor (about 9fps) if the demo is running in Chromium 36.</p></blockquote><br />
<br />
== Proposed Solution ==<br />
<br />
=== Batch versions of drawImage ===<br />
:New batch variants of drawImage that accept array arguments.<br />
<br />
==== Processing Model ====<br />
:We would have new variants of the existing drawImage method where the numerical arguments are are packed into a Float32Array. The image argument may or may not be an array. If it is not an array, the same source image is used for for each draw. When rendering from a single sprite sheet, it would be preferable to not specify the image argument as an array in order to minimize bindings overhead and redundant parameter validation.<br />
<br />
==== Suggested IDL ====<br />
<br />
<pre><br />
<br />
enum CanvasDrawImageParameterFormat { position, destination-rectangle, source-and-destination-rectangles, source-rectangle-and-transform};<br />
<br />
interface CanvasRenderingContext2D {<br />
...<br />
void drawImageBatch(sequence&lt;CanvasImageSource> image, CanvasDrawImageParameterFormat parameterFormat, Float32Array drawParameters);<br />
void drawImageBatch(CanvasImageSource image, ParameterFormat parameterFormat, Float32Array drawParameters);<br />
}<br />
</pre><br />
<br />
:The drawParameters argument is to be interpreted as a table in row-major order. Where each row represents a single draw and each column represents an individual parameter. The mapping of the columns to draw parameters depends on the parameterFormat argument.<br />
:* position: dx, dy<br />
:* destination-rectangle: dx, dy, dw, dh<br />
:* source-and-destination-rectangles: sx, sy, sw, sh, dx, dy, dw, dh<br />
:* source-rectangle-and-transform: sx, sy, sw, sh, a, b, c, d, e, f<br />
<br />
:The parameters sx, sy, sw, sh, dx, dy, dw, and dh have the same meaning as with drawImage()<br />
:The parameters a, b, c, d, e, f have the same meaning as with transform()<br />
:With 'source-rectangle-and-transform' the destination rectangle is a unit square defined by the vertices (0, 0), (1, 0), (1, 1), and (0, 1). The destination rectangle is transformed by the transform defined by a, b, c, d, e and f, and the by the canvas's current transform.<br />
<br />
Feedback Anne: Perhaps rather than overloading we should introduce new methods? IDL overloading is somewhat costly and not loved much by the JS community. Also, please float this by public-script-coord@w3.org at some point.<br />
<br />
Feedback Jonas: Yeah, something like drawImagePositionBatch/drawImageDestRectBatch/drawImageSrcAndDestRectBatch/etc will make feature detection of future expansions easier. See [http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html]<br />
<br />
==== Exceptions ==== <br />
<br />
:An INDEX_SIZE_ERR DOM exception is thrown if the size of drawParameters is not a multiple of the number of numeric parameters corresponding to 'parameterFormat'<br />
:An INDEX_SIZE_ERR DOM exception is thrown if 'image' is a sequence and the size of drawParameters is not equal to the number of elements in 'image' multiplied by the number of parameters corresponding to 'parameterFormat'.<br />
:All the same exceptions that apply for calls to drawImage also apply to drawImageBatch. If any individual draw results in an exception being thrown, the entire call to drawImageBatch must abort without drawing anything to the canvas.<br />
<br />
==== Limitations ==== <br />
<br />
:The use of Float32Array is not very programmer friendly. This compromise on usability is justified by performance considerations, and is necessary to achieve near-native or WebGL-like performance.<br />
<br />
==== Implementation ==== <br />
* The most naive implementation, which would consist in expanding the batch drawImage call into multiple internal drawImage calls would already increase performance by reducing API bindings overhead.<br />
* The use of typed arrays will dramatically reduce the argument type checking burden in the bindings.<br />
* More advanced implementations would carry the batching down to a lower level in the graphics stack. For example, a GPU-accelerated implementation of 2D canvas could use OpenGL vertex buffer objects, or the DirectX sprite interface.<br />
* Some existing implementations of drawImage already detect batching opportunities and will batch consecutive drawImage calls at a lower lever of the graphics stack (for example skia's drawBitmap used in Blink). This auto-detection does improve rasterization performance, but it does not eliminate the bindings overhead and it involves additional overhead to determine whether consecutive calls to drawImage can be grouped together to form a batch. With explicitly batched calls to drawImage, that overhead can be eliminated because the individuals sprite draws would be known to use identical rendering context state, and the calls down to the graphics platform implementation layer would only occur once for the entire batch.<br />
<br />
==== Adoption ==== <br />
:Game/app devs looking for high frame rates for sprite blitting are likely to adopt enthusiastically.<br />
<br />
[[Category:Proposals]]</div>Sickinghttps://wiki.whatwg.org/index.php?title=Input_element&diff=9477Input element2014-03-05T19:54:56Z<p>Sicking: /* new datetime input discussion */</p>
<hr />
<div>{{stub}}<br />
<br />
Research, data, use cases, issues, and enhancements related to the HTML5 <code>input</code> element.<br />
<br />
__TOC__<br />
<br />
== new date time inputs ==<br />
The current new date time inputs cover a number of interesting and broad use-cases of various levels of granularity for absolute date and time input types:<br />
<br />
<pre><br />
* month (specific year, month)<br />
* week (specific year, week (implied month(s)))<br />
* date (specific year, month, day)<br />
* datetime (specific year, month, day, time)<br />
* datetime-local (specific year, month, day, time, timezone)<br />
</pre><br />
<br />
As well as one floating time input:<br />
<pre><br />
* time (specific time, but no specific day, month or year)<br />
</pre><br />
<br />
This set is missing a few date time inputs that would make sense in such a more complete collection of granularity and floating (non-absolute) date time inputs:<br />
<br />
<pre><br />
* year NEW: (specific year)<br />
* month (specific year, month)<br />
* week (specific year, week (implied month(s)))<br />
* date (specific year, month, day)<br />
* datetime (specific year, month, day, time)<br />
* datetime-local (specific year, month, day, time, timezone)<br />
</pre><br />
<br />
and<br />
<br />
<pre><br />
* month-day NEW: (specific month, day)<br />
* time (specific time, but no specific day, month or year)<br />
</pre><br />
<br />
=== new datetime input use-cases ===<br />
* year - see the [[Time_element#year_only|time element year only use cases]]<br />
** pull-down for Wikipedia which lets you choose the year or period<br />
** a charting application which looks at trends in history<br />
** e-commerce: buying, say, automobile or building insurance and specifying the year of manufacture/ construction<br />
* month-day - see [[Time_element#month_day_only|time element month day only use cases]]<br />
** inputting a birthday without birth year<br />
** entering custom annual holidays<br />
** searching an "on this day in history" archive e.g. [http://www.scopesys.com/anyday/]<br />
* Non-Gregorian/ BC dates<br />
** The [http://collections.vam.ac.uk/ Victoria & Albert Museum's collections search] uses a drop-down menu to select BC/AD on the date fields<br />
<br />
Additional use-cases for each of these new inputs are documented in proposals for allowing the respective levels of granularity/floating date/time support in the [[time element]].<br />
<br />
=== new datetime input discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - any implementer that is going to the trouble of properly implementing the existing 6 new date time inputs will find it fairly easy to implement two additional variants, and this more complete model of date and time inputs will be easier to remember for web authors (fewer exceptions to remember).<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] - Per the above, and examples/ use cases on [[time element]].<br />
* +1 [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027826.html Ryosuke Niwa on whatwg list] - "... to implement that, we need to know that certain text field is accepting "year", not a 4-digit number."<br />
** +0 [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027828.html Aryeh Gregor on whatwg list] - "I agree, this is a valid reason to want a year input. I can't say whether it's good enough to add it to the spec, given how many input types we have already and how little implementation has been done so far, but it's a legitimate argument."<br />
** +1 [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027829.html Jonathan Castello on whatwg list] - "That's probably the most convincing point for adding a "year" type I've heard so far. I'd agree with a "year" type just based on that."<br />
* +1 Sicking - The extra implementation cost is pretty low, and the uses are common enough. It's also tricky to work around the lack of day+month input since you can't leverage the existing controls, but rather have to start from scratch. However I think we should use the string "day-month" rather than "month-day" since most of the world, including most of the world that uses the english words "day" and "month", puts day before month. See [http://en.wikipedia.org/wiki/Date_format_by_country]<br />
* ...<br />
</div><br />
<br />
=== new datetime input FAQ ===<br />
==== how is a year different than a four digit number ====<br />
'''Question:''' How is a "year" input any different from a four-digit input type="number" field?<br />
<br />
'''Answer:''' It's not "just" an alias. It is very similar, however different in that:<br />
* It has the *semantic* of being a year, which is a special type of number (potentially more than four digits if you subscribe to "Long Now" methodology.<br />
* This semantic gives browsers the opportunity to present a "year" picker control that is styled in appearance consistently with other datetime inputs (rather than just a number input)<br />
* This semantic gives robots the opportunity to understand that a form takes time based information rather than just a number (if for example robots perform time based form submissions/searches on our behalf at some point)<br />
* Years can also be more of fewer than four digits. Julius Caesar was born in 100 BC, for instance, while Manius Acilius Glabrio was consul in 91 AD.<br />
** Sites requiring BC and/ or 1/2/3- digit year entry: [http://www.mayabelize.ca/maya/maya-long-count-generator.shtml], [http://www.smart.net/~mmontes/ec-cal.html], [http://www.guernsey.net/~sgibbs/roman.html]<br />
<br />
==== how does year provide additional validation ====<br />
'''Question:''' What sort of additional validation you would need in a year field that you couldn't accomplish with "number" with a size of 4?<br />
<br />
'''Answer:''' See above for the additional semantics that a year provides above and beyond a 4 digit number (and that years are not necessarily 4 digits). One source of additional validation could come from only permitting years since the transition to the Gregorian calendar, unless another calendar scale is specified (see related [[Time element]] proposal).<br />
<br />
==== how would a year input appear in visual UAs ====<br />
'''Question:''' How would such an input would appear in visual UAs?<br />
<br />
'''Answer:''' The specific visual appearance is up to UA designers. Currently there is quite a bit of variance/experimentation of what datetime inputs look like from browser to browser (e.g. Safari, Opera), or even across different versions (Opera 10.55 vs 10.6) or even across devices (Mobile Safari vs. Safari).<br />
<br />
== See Also ==<br />
* [[time]] - the time element, related proposals.<br />
<br />
[[Category:Proposals]]</div>Sickinghttps://wiki.whatwg.org/index.php?title=Canvas&diff=7631Canvas2011-11-12T00:24:22Z<p>Sicking: /* Real world uses of Canvas */</p>
<hr />
<div>= Real world uses of Canvas =<br />
<br />
List some real-world examples of uses of canvas that are examples of things best done with canvas and not other features of HTML:<br />
<br />
* https://zewt.org/curves/<br />
* http://www.blobsallad.se/iframedsallad.html<br />
* http://www.htmlstack.com/checkbox/<br />
* http://shapecatcher.com/index.html<br />
<br />
= Limitations of real-world use cases =<br />
<br />
In this section, discuss specific examples from the list above and explore what those use cases fail to do (e.g. in terms of accessibility) which they should do. <br />
<br />
;https://zewt.org/curves/<br />
:Keyboard users can't tab to specific points and move them from the keyboard.<br />
:* Should show focus ring around the selected point when moving by keyboard movement.<br />
:Limited-vision users can't zoom around the specific area that the user is manipulating.<br />
:It's a pity the mouse cursor has to be manually changed onmousemove.<br />
<br />
= Proposals =<br />
<br />
In this section, propose alternatives to improve canvas to make it easier to fill in the limitations listed in the previous section.<br />
<br />
<br />
= Examples =<br />
<br />
Take the pages from the first section and show how they would be changed to use the proposals in the previous section.<br />
<br />
[[Category:Proposals]]</div>Sicking