Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)
On Jan 23, 2014, at 10:52 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/23/14 9:13 PM, Bruno Racineux wrote: Could 'resource control' be an associated spec of the 'hidden' attribute? It bothers me, at first glance, to overload the attribute to mean different things. I predict people will appear who want the hidden thing to hide but still want loading/preloading. It would be better to just have a separate attribute for the separate task if we go this direction. In addition to overloading `hidden`, it misses the `postpone` use case of images that we want to be visible (i.e. not have a `hidden` attribute), but not loaded until/unless the user scrolls enough for them to be within the viewport.
Re: [whatwg] OUTPUT tag: clarify purpose in spec?
2014-01-22 2:28, Ian Hickson wrote:
On Tue, 3 Dec 2013, Jukka K. Korpela wrote:
[...]
Thank you for the clarifications. I may have been stuck to an idea of a
submittable element, possibly adopted from some earlier version or
proposal. I think an explicit short note like The output element is not
submittable would be useful.
I am reluctant to add that kind of comment for a couple of reasons. First,
there's the problem of determining when one would add these notes. Should
the spec be explicit about everything it doesn't say?
No, but it should be explicit about things that could easily be
misunderstood.
Second, it can lead readers to assume that anything that the spec doesn't
explicitly call out as not being true is in face true
Readers who wish to think so may think so anyway. I don't see how this
could be a serious risk.
What I would rather do is clarify whatever led to the confusion in the
first place. Do you have any idea what it is in the output section that
might lead you to think that it would be submittable?
Well, it is under the heading 4.10 Forms. As an element for the result
of some scripted operation (which output seems to be meant for),
output need not have anything to do with forms. But when it is under
Forms, a natural idea is oh, this is for some computed value, like a
total, to be submitted.
(A submittable output element would a natural thing to have in many
cases, e.g. in showing some calculated total to the user and submitting
it along with form data, for checking purposes.)
Can you elaborate on this use case? I'm not sure how it would work.
When you calculate the total with JavaScript, mainly to be shown to the
user, you might as well submit it along with the form, as an extra
check. If it does not match the total calculated in the server,
something went very wrong. What you do then is a different question, but
the important thing is that you detect a problem, instead of charging an
amount that differs from what the user saw.
The main reason for not submitting it so far has been that it would risk
authors relying on the client's computation and thus not doing it on the
server,
Authors often rely too much on checks and computations made client-side
- including new features like @pattern and @required attributes and new
values of the @type attribute. They have always been able to do that
with calculated totals, for example - just using an input element
(possibly with @readonly).
I think the definition of the @name content attribute needs revision. It
now says: Name of form control to use for form submission and in the
form.elements API. Apparently, form submission should be omitted.
Aah, interesting. Yeah, that's confusing. The attribute is a generic one
used by multiple elements for both those purposes, but in the case of
output and fieldset, it can never be used for form submission, since
those aren't submittable, so it should use a different description.
Fixed.
The single-page version now has Name of form control to use in the
form.elements API, but the multi-page version still has the old
formulation.
Without name=, the main purpose of output -- making it easy to update
non-form-control values in script -- is lost.
The @name attribute in general, except for submittable controls, is
legacy markup that has caused much confusion. It was introduced long
ago, before @id was added to HTML, for scripting purposes, on @img and
@form, as well as on @a for link destinations, but it was unsuitable
from the beginning. It was not defined to be unique in the document, and
there have been many attempts to phase out/deprecate/obsolete @name
(except for submittable fields, where it need not be unique).
So it looks a bit odd to introduce @name for a new element.
Consider what this would look like without the form.elements API:
form name=main
Result: output name=result/output
script
document.forms.main.elements.result.value = 'Hello World';
/script
/form
With output id=result/output, it would have
document.getElementById('result').value = 'Hello World'
and if jQuery is used (and more than half of the world uses it, or
something similar), it would have
$('#result') = 'Hello World'
I would say that both ways are simpler than the property chain
document.forms.main.elements.result.value and, moreover, a way that can
be used to access any element, not just output.
Well, more or less by definition, of output is appropriate for
something, it's more appropriate than span would be, since span is
more generic. span is like the fall back element, it has essentially
no semantics at all.
That's a rather theoretical proposition. You say that output is for a
result of a calculation or user agent and call this semantics. But how
would that be a tangible benefit.
I think the improvement of o relative to document.getElementById('o')
should be self-evident;
If you intend to use plain o instead of a property
[whatwg] Drawing shapes on canvas
Rik,
From the Skia perspective we have the following feedback on the proposal.
While we can see how Shape2D can be implemented, it isn't clear that it's
such a large performance benefit over what Path provides, so we aren't
opposed to Shape2D, but don't believe implementing Path should be held up
for the sake of Shape2D. Path itself is a huge win for performance over
having only a single current default path and has utility without the need
for Shape2D.
In general we would like to see a layered approach to drawing objects,
starting with something primitive like Path, and at the most general a
Display List[1] that contains the full set of capabilities of
CanvasRenderingContext2D. That layering could be done in two or three
objects, either [Path, DisplayList] or [Path, Shape2D, DisplayList]. In
all
cases you can use the lower level objects to construct higher level
objects,
i.e. use one or more Paths to build a Shape2D, and use Paths and Shape2Ds
to
define a DisplayList.
What we'd like to see happen:
1. Review the Path add* methods and possibly simplify them, see below.
2. Keep the rest of the Path object and the Path related methods on the
CanvasRenderingContext2D.
3. If Shape2D moves forward do it by adding different versions of fill,
clip, etc to CanvasRenderingContext2D, such as:
void fill(optional CanvasFillRule fillRule = nonzero);
void fill(Path path, optional CanvasFillRule fillRule = nonzero);
void fill(Shape2D shape);
4. Possibly work on a DisplayList design, but only after some
experimentation.
We have some particular feedback on the Shape2D design that is inline
below:
[1] http://en.wikipedia.org/wiki/Display_list
All,
around a year ago, I wrote a blog post [1] that introduced a new 'Shape'
class that described a filled or stroked region or an area of text. Java2D
has a similar concept that they call 'Area' [2].
We've had some discussions but it doesn't look like there was any sort of
conclusion. I'd like to pick it back up now that we have a partial
implementation of the Path object and people are starting to look into
extending it.
I'll reiterate my proposal:
1. remove all the addxxx methods from the Path2D object [3]
Path object are just containers for segments. Aggregating segments will
generally not give the desired results since the segments will interact
(see [1]).
AddPath *could* be kept if people see a strong use case.
The add* methods could be simplified to:
void addPath(Path path, SVGMatrix? transformation);
void addPathByStrokingPath(Path path, CanvasDrawingStyles styles,
SVGMatrix? transformation);
void addText(DOMString text, CanvasDrawingStyles styles, SVGMatrix?
transformation, unrestricted double x, unrestricted double y, optional
unrestricted double maxWidth);
void addTextAlongPath(DOMString text, CanvasDrawingStyles styles,
SVGMatrix? transformation, Path path, optional unrestricted double
maxWidth);
The functionality of the addPathByStrokingText methods below can be done by
applying the above methods.
void addPathByStrokingText(DOMString text, CanvasDrawingStyles styles,
SVGMatrix? transformation, unrestricted double x, unrestricted double y,
optional unrestricted double maxWidth);
void addPathByStrokingText(DOMString text, CanvasDrawingStyles styles,
SVGMatrix? transformation, Path path, optional unrestricted double
maxWidth);
2. introduce a new class 'Shape2D'
Interface:
[Constructor,
Constructor(Path2D , CanvasWindingRule = nonzero),
Constructor(Path2D , CanvasDrawingStyles, SVGMatrix?), // strokes a path
Constructor(DomString text, CanvasDrawingStyles, SVGMatrix?,
unrestricted
double, unrestricted double, boolean isStroked = false, optional
unrestricted double)]
interface Shape2D{
Shape2D transform(matrix); // returns a transformed path
Why not do this as another constructor?
Constructor(Shape2D, SVGMatrix)
Shape2D add(Shape2D); // returns a path that is the union of the 2
paths
Just to clarify, add() means a union of the two shapes, with no side-effects
resulting from winding rules of the individual path?
Shape2D seems reasonable and useful just as an immutable capture of all
coverage aspects of geometry. If add() is hard for platforms to support,
or
is expensive and clients don't know that, perhaps we can leave it out of
this
version. If we really want to have add(), why not include the full
compliment
of Set operations [ diff, xor, intersect ], which are no harder to
implement
(afaik) once you've implemented add().
}
This class will represent a painted area. Because it knows the winding and
stroking rules, the browser will be able to do expensive math in advance.
It can also cache the region on the GPU.
constructors:
a. default constructor that creates an empty region
b. constructor that take a path and a winding rule. This represents a
filled region
c. constructor that takes a path,
Re: [whatwg] Proposal: Change HTML spec to allow any arbitrary value for the meta name attribute
On Tue, 4 Jun 2013, Michael[tm] Smith wrote: The context of the proposal is the following language in the HTML spec: Conformance checkers must use the information given on the WHATWG Wiki MetaExtensions page to establish if a value is allowed or not: values defined in this specification or marked as proposed or ratified must be accepted, whereas values marked as discontinued or not listed in either this specification or on the aforementioned page must be rejected as invalid. http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#other-metadata-names I propose we remove that language from the spec [...] For the past few years, we've been running an experiment here, getting people to register values on the wiki: http://wiki.whatwg.org/wiki/MetaExtensions We also have the rel extensions registry on the microformats wiki. Before we go further, we should probably discuss the problem that we're trying to solve with these registries, instead of just allowing any value to be used. These are the same reasons as for most things we make non- conforming at the authoring level: - helping authors catch cases where their intent is unclear - helping authors catch typos - helping authors avoid known interoperability issues - helping authors avoid wasting time (See also: http://whatwg.org/html#conformance-requirements-for-authors ) There's also the goal of just documenting what's out there, to help people who want to invent new values to avoid reinventing the wheel, or at least, to avoid reinventing it poorly. I think these goals are reasonable, and worth pursuing. We could just have wide-open extension points here, allowing any value, not bothering to define any. But I think this would be a net loss. From the aforementioned experiments with wiki registries, we've learnt several things, which I shall now discuss. Some of these are taken from mailing list discussions on this thread; thanks to the contributors thereto. Others are taken from IRC discussions earlier this week; thanks to Tantek and MikeSmith in particular for their comments: http://krijnhoetmer.nl/irc-logs/whatwg/20140122#l-552 http://krijnhoetmer.nl/irc-logs/whatwg/20140123#l-88 The first big lesson is that, maybe surprisingly, there's a lot of demand for these features. The long tail of needs for these values is very long indeed. Well over a hundred meta name keywords have been registered, and that ignores all the ones that people haven't bothered to register. Simultaneously, people are unhappy when validators don't know about their meta names. The modern HTML validators point people to the Wiki; for example, validator.nu says: You can register metadata names on the WHATWG wiki yourself. People follow the link and attempt to register values all the time. The barrier to adding values has been low, but still not trivial: you have to e-mail a request for a wiki account, then when you get it a few days later, you have to add the item to the wiki page which means editing MediaWiki's table markup. We get a few requests for accounts each week. We also get a number of people each week filing unclear bug reports on the spec asking, I think, for certain values to be registered. One lesson from this is that we could make this much easier, e.g. by having validators offer to register the keyword directly. The wikis for meta name and link rel have been wildly more successful than IETF/IANA registries, at least in terms of how many keywords they document. This is, presumably, due to the lower barrier for entry. If a goal is to document values used on the Web, then lowering the barrier to entry even further might increase the volume of documentation. Another lesson, though, is that if we make certain values non-conforming, we'd better have a rather convincing message for the validators to give the authors. Such messages should probably include an explanation as to why a value is non-conforming and a description of how to achieve the desired effect instead. Right now, the message is just Bad value ... for attribute name on element meta: Keyword ... is not registered. This may be the best we can do for unknown values (though maybe we could do better for typos, pointing people to the keyword they probably meant to use?), but if we start marking values as non-conforming because of issues with the values, we need to be clearer. Right now, for link rel extensions we have the concept of synonyms. This probably isn't sufficient for validators, though, and we don't have it at all for meta. Another anectodal data point is that based on the conversations I've had with people trying to register accounts on the WHATWG wiki so they can register keywords, many authors have no idea what these keywords are really for, despite being very sure they want to have them and not wanting validators to complain about them. I don't know what we can do about that, though.
Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)
On 1/24/14 7:35 AM, David Newton da...@davidnewton.ca wrote: On Jan 23, 2014, at 10:52 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/23/14 9:13 PM, Bruno Racineux wrote: Could 'resource control' be an associated spec of the 'hidden' attribute? It bothers me, at first glance, to overload the attribute to mean different things. I predict people will appear who want the hidden thing to hide but still want loading/preloading. It would be better to just have a separate attribute for the separate task if we go this direction. In addition to overloading `hidden`, it misses the `postpone` use case of images that we want to be visible (i.e. not have a `hidden` attribute), but not loaded until/unless the user scrolls enough for them to be in the viewport. I am not necessary saying that it should replace 'postpone'. Though note again as I mentioned that 'postpone' is currently dead per: http://lists.w3.org/Archives/Public/public-web-perf/2013Nov/0099.html I am not sure what happens to the use case you mention;'lazyload' doesn't cover it and I don't recall it it did when before 'lazyload' was split into lazyload+postpone. But because without css 'postpone' can't work. That's Where 'hidden' actually helps implementing the 'postpone' functionality. 'Postpone' could exist separately as jit for that image lazy-loading case. The requirement for ATs with 'hidden' is to access the structure of hidden elements. Not the presentation aspect... I am having a hard time translating that a resources that is not yet needed or is no longer needed means that it should load immediately *regardless*. In practice that is not the case. The 'not yet' may never happen... Yet we decide to preload something 'hidden' which the UserAgent is asked not to render. It doesn't compute for me... And I am not trying to overload 'hidden'. I am strongly conveying that by design, 'hidden' should not load right away as currently implied by current specs. The question become when does 'hidden' ought to load. It can load 3 ways: 1. Lumped into preloading like everything else, 2. On DOMContentLoaded or 3. Just-in-time loading. Either option 2 or 3 seem perfectly legitimate choices. But I strongly disagree with option 1 as default. 'hidden' indicate a lower priority. Preloading 'hidden' elements seems just wrong in the first place. It introduces backward resource priorities. On 1/23/14 7:52 PM, Boris Zbarsky bzbar...@mit.edu wrote: Not only the pre-loader doesn't load the data-src but image.png doesn't actually load at all. How did you determine that last, if I might ask? Right, it's only webkit. My test were just follow-ups on Kornel's initial discovery: https://twitter.com/pornelski/status/405704147678535680 One false hope for potentially using object as responsive image polyfill (or actual solution) because IE doesn't wait for the document 'interactive' state or documentready like Firefox or Webkit do, and so altering object with JS prior to its resource loading is a no-go in IE... Just for the context. On 1/23/14 7:05 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Not only the pre-loader doesn't load the data-src but image.png doesn't actually load at all. You're assuming that object preloads at all. Considering the pre-loader loads everything displayed or not, yes. That's not for misinterpreting any documentation though. And there is in fact a webkit bug, and/or oversight in implementation with object. -Bruno
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Tue, 7 Jan 2014, Dominic Mazzoni wrote: On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson i...@hixie.ch wrote: If the user needs a big ring, it seems bad for us not to render one. Especially since we can know this. Yes, there are users who need extra high-contrast focus rings. But no, they don't get that from an operating system setting that the app queries, I think that's the source of the confusion. Try checking the Make the focus rectangle thicker checkbox in Windows. Any time where a single-pixel dotted outline was shown before, you'll now see a 2-pixel dotted outline. However, in every application I tried, when previously you saw a custom focus highlight (which is the majority of the time - the dotted outline looks very dated), there's no change - including in Windows explorer, Office, IE, Firefox, etc. - I just don't see any precedent for applications that already provide custom focus highlighting to do something different when the Make the focus rectangle thicker option is checked. Why isn't this just a widespread accessibility bug? If you want to give the AT position information when there's no visible focus ring, that's what addHitRegion() is for. For the record, I like addHitRegion and I'd like to go forward with implementing it too. Do you consider it ready for implementation? Yeah, I'm not aware of any outstanding work for it right now. Have any other browsers expressed interest? I do not recall specific comments from browser vendors one way or the other. The impression I got a while back was that there were still concerns from some people. I'm not aware of any outstanding concerns. We should probably start a new thread on addHitRegion if there's anything to discuss, and keep this one focused on drawSystemFocusRing, since that's the one that it appears three browsers have implemented now. (I'm assuming IE is implementing it, given that Microsoft has publicly commented on the spec.) The reason I think it's relevant is that if what people want drawSystemFocusRing() to do is in fact what addHitRegion() does, then we should not do both. It wasn't my intent to implement something different than the spec. The spec only talks about the accessibility part of the implementation in a Note explaining the meaning of Inform the user, which I didn't think was normative. I took the language in that note as a guide but ultimately tried to implement something that actually works. I made a simple demo app to demonstrate the use of this API, and tested it with three screen magnifiers while developing it. I apologise that the spec was misleading in its note. I've tried to update the spec to remove this confusion (and made the new paragraph normative.) I think in practice it may be that for accessibility the right thing is for authors to use addHitRegion(), and the focus ring drawing APIs should only draw the focus ring and do nothing else. On Tue, 7 Jan 2014, Rik Cabanier wrote: On Tue, Jan 7, 2014 at 9:45 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 7 Jan 2014, Rik Cabanier wrote: I believe this is where part of our confusion/disagreements come from. The draw*FocusRing methods are NOT direct-mode APIs for *a11y*. Right. They're not really APIs for accessibility at all. They're about drawing focus rings. No. The only reason for this API is accessibility. That was not the primary intent of the APIs. (Accessibility, like security, performance, or internationalisation, is almost never the primary intent of a well-designed API, since accessibility, like security, performance, and internationalisation, are concerns that permeate _every_ API and well-designed APIs make them non-issues.) An author could just check the focused state and draw the ring himself; there's no need for an API to do this. There's no way to draw a focus ring that has the appearance of the platform's focus rings without an API for it. By calling draw*FocusRing on a fallback element, the a11y software will now associate that element (and its aria rules) with the path that was in the canvas' state. This is non-conforming behaviour that is incompatible with the API design. Doing this will cause harm, because the API is incapable, as designed, of being used in this manner correctly without causing bugs. For example, if, when an element is not focused, it's split into four parts, there's no way to draw a single focus ring around it. Thus the data about that control's position _will be incorrect_ if the UA relies on this method for this data. I don't understand. The path for the focus ring can be anything, including multiple closed paths. The data for the a11y software won't be wrong, it will be the boundingbox of those paths. Right. If the intent, however, is for one part of the element to be magnified, and the other parts to just be decorative, then this would result in the
Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)
On Fri, Jan 24, 2014 at 9:09 PM, Bruno Racineux br...@hexanet.net wrote: The requirement for ATs with 'hidden' is to access the structure of hidden elements. Not the presentation aspect... I am having a hard time translating that a resources that is not yet needed or is no longer needed means that it should load immediately *regardless*. That seems like it should be up to the user, and, thus, the user agent, yes? The question of whether and what to preload strikes me as very much contingent on the priorities and circumstances of individual users, and obviously not at all the authors' business. I find the entire subject of specifying how user agents should preload completely misguided. Shouldn't this, if *anything*, be open for innovation?
Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)
On 1/24/14 7:37 PM, Qebui Nehebkau qebui.nehebkau+wha...@gmail.com wrote: On Fri, Jan 24, 2014 at 9:09 PM, Bruno Racineux br...@hexanet.net wrote: The requirement for ATs with 'hidden' is to access the structure of hidden elements. Not the presentation aspect... I am having a hard time translating that a resources that is not yet needed or is no longer needed means that it should load immediately *regardless*. That seems like it should be up to the user, and, thus, the user agent, yes? This is not about user-agents. Not sure what you are getting at... The question of whether and what to preload strikes me as very much contingent on the priorities and circumstances of individual users, and obviously not at all the authors' business. I find the entire subject of specifying how user agents should preload completely misguided. Shouldn't this, if *anything*, be open for innovation? What exactly do you find misguided, can you be more specific?
