Hi Tab,
You wrote:
Sounds acceptable to me. What's the grammar of color=''? Just hex,
or full CSS color? (Either is fine with me.)
We support full CSS colors. Though, we ignore the alpha component.
Cool. When are we going to see a spec for this? ^_^
Well, typically what happens is people
Hi,
Kornel wrote:
Safari[…] uses `theme-color` for foreground color of favicons of
pinned tabs, but other browsers use `theme-color` for background
colors.
I replied:
Well, meta name=theme-color is not specced as speficially a
foreground or background color; it's a color that user agents
Hi Anne,
You wrote:
On the other hand, link rel=mask-icon color=darkslategray seems
like it should Just Work™.
I guess we could add support for named colors to input type=color
too.
Offhand I think that's a good idea. Probably won't round-trip through
typical color picker implementations,
Hi Elliott,
You wrote:
I'm fine with either interpretation, mask-icon or icon mask like
alternate stylesheet. I don't think adding a mask attribute to the
HTMLLinkElement for this makes sense.
Could you elaborate? It's not clear to me why link rel=icon mask
wouldn't make sense, but link
Hi all,
Kornel wrote:
Safari[…] uses `theme-color` for foreground color of favicons of
pinned tabs, but other browsers use `theme-color` for background
colors.
Well, meta name=theme-color is not specced as speficially a foreground
or background color; it's a color that user agents may use in
When link is used to pull in external resources, authors may use
several attributes as hints about the linked resource to help UAs decide
whether or not to load it.
For instance, the resource's MIME type may be provided in the type
attribute. This allows UAs to avoid loading resources they don't
Hi Anne,
You wrote:
Our proposal is simply to add mask= to this list of advisory
attributes that are used to determine an icon's appropriateness here.
User agents that don't understand mask= should continue to pick the
most appropriate icon given the other attributes. If there is a tie,
the
Hi Mounir,
I would like to standardize the Apple's proprietary autocapitalize
attribute. This attribute is widely used and it would probably benefit
the platform to have a broader support for it. The implementation cost
should be fairly low while it can be very beneficial for the user
Hi,
Anne wrote, last year:
There are a couple of scenarios
http://notifications.spec.whatwg.org/ does not address at the
moment.
A) User navigates to chat site. Chat site creates a notification
from a chat with P while the user does something else. User closes
chat site and then navigates
Hi,
In §4.6 Activating a notification, there's a note that currently reads
User agents are strongly encouraged to make window.focus() work
from within the event listener for the event named click as a means
of focusing the browsing context related to the notification.
This note
Hi,
Ian wrote:
Is there any reason to have two fields here, why not just new both
times?
That works for me. Browsers can supply the same value for multiple
autocomplete=new-password fields in the same form.
Also, should we have an old field for the old password, or is the
lack of an
Hi,
The consensus opinion at WebRTC and MediaCapture seemed to be that
the ability to let an app say which of these 5 microphones do you
want? is more amenable to creating good apps than leaving this UI to
the browser chrome.
Seems to me that the privacy aspects (the fingerprinting
Hi Rik,
You wrote:
Currently, the specification states that if you create a region and
then create another region that completely covers region, the first
region is removed from the hit region list [1]
This is a complex operation that involves either drawing the regions
to a bitmaps and
Hi,
Ian wrote, in 2012:
This might fall under the broader class of identity-related fields,
which I think merit their own carefully thought out set of tokens.
There was some work done on the beginnings of such a specification --
see https://wiki.mozilla.org/Identity-inputs -- but my current
Hi Henri,
You wrote:
Just like AppCache, srcset is not something that you can iterate on.
You can't add features without breaking compatibility.
This is incorrect. The srcset= parser is specced such that new
descriptors can be added in a backwards-compatible way.
Ted
Hi,
[W]e do want users to be able to bring up the native controls via a
context menu and be able to use them regardless of what the page
does in its event handlers. So, I request that the spec be explicit
that interacting with the video controls does not cause the normal
script-visible
Hi Ian,
You wrote:
On Wed, 30 Jan 2013, Peter Carlson (carlsop) wrote:
Problem: The problem is that the supported playback speeds of a media
element may vary per media item (e.g., an on-demand movie) and as
[…]
Recommendation: We suggest that the application should be able to
discover
Hi,
I don't recall if this was in person or in email, but I think Tab made a
compelling argument in favor of changing the implementation of hidden=
to be
[hidden] {
display: none !important;
}
in the UA stylesheet.
Consider a bunch of thingies, represented in the DOM with a pile of
Hi,
The spec currently disallows conformance checkers from reporting img
elements without alt= attributes as an error when meta
name=generator is present[1].
This is problematic for two reasons:
1. Many tools which insert meta name=generator have done so for years
simply as a means to mark
Hi,
Currently, there are only two ways to invoke the clear regions that
cover the pixels algorithm: by calling either addHitRegion() or
clearRect(). Authors should be able to explicitly remove a hit region as
well, with a removeHitRegion(id) method.
Consider a region of a canvas which the author
Hi,
As things currently stand in the spec, implementations basically need to
keep N+1 bitmaps per canvas, where N is the number of hit regions. I
doubt any implementors would be enthusiastic to implement hit regions
like this. From a WebKit perspective, we'd much prefer keeping a Path
for each
Hi,
When authors adapt their sites for high-resolution displays such as the
iPhone's Retina display, they often need to be able to use different
assets representing the same image. Doing this for content images in
HTML is currently much more of a pain than it is in CSS (and it can be a
pain in
Aryeh wrote:
I'd like to throw in another use-case that might be addressable by the
same feature: allowing Save As... to save a different version of the
image (e.g., higher-res) than is actually displayed.
[…]
Another obvious use-case I'd like to point out is print.
Yes, these are both
Hi,
This proposal has a similar issue to image-set() - if the 2x means
twice the resolution (which it should), this will *not work by
default*.
Just a quick update for the list—Tab and I chatted about this F2F just
now and we agree that there isn't really a problem here, so long as the
spec
Ojan wrote:
Escape usually calls cancel on dialogs, no? Seems to me that if you
have a dialog open, esc should cancel the dialog, otherwise it should
yank all fullscreened elements.
Doesn't this suffer from the same sort of security attack that requires
us to leave all fullscreened elements
Hi Ian,
You wrote:
It would be unfortunate to have to reserve the use of a name as
generic as translate for a particular library.
Indeed. That said, the name translate already means something in the
platform—it's used by CSS transforms and by the canvas 2D Context API.
Wink's usage of the
Hi Darin,
You wrote:
The alternative requires a fair bit of code to construct an overlay,
etc.
Part of the idea of dialog is that the UA takes care of the (otherwise
painful) overlay setup etc. for you.
Ted
Hi,
Unfortunately, lots of canvas content (especially content which calls
{create,get,put}ImageData methods) assumes that the canvas's backing
store pixels correspond 1:1 to CSS pixels, even though the spec has been
written to allow for the backing store to be at a different scale
factor.
Tab wrote:
So, I support adding an alternate API that explicitly returns a
high-res store. If people fuck *that* up, then we're just screwed.
Yup.
I'm not as sure about the backingStorePixelRatio bit. What's the
use-case for it? Why do devs need to detect this, and what will they
do
Charles Pritchard wrote:
But now run through this logic when the canvas is making a high res
backing store automatically: by doing the clever thing, you're now
quadrupling the size of the canvas, and you're paying an exorbitant
storage cost for doing so.
Which (a): never happens
Sorry,
John Knottenbelt wrote:
How should the data url returned by toDataURL be sized in the case of
a high device dpi resolution system? E.g. where the canvas's backing
store horizontal and vertical dimensions are some multiple of the
specified width and height in CSS pixels.
In the case of
Robert O'Callahan wrote:
I think we should go the route that the dialog element did in Ted's
change proposal and have a pseudo-element that gets created when an
element is fullscreened. Simple and easy, and trivial for the author
to manipulate to get most effects they could want.
Hm, why would it require stacking-level changes? One obvious way to
get it to act correctly is to make it wrap around the element, like
the old ::outside pseudo-element proposal. Then it's trivial.
The CP says The dialog and its cover, taken together, are siblings within a
new stacking
Hi,
Re: http://krijnhoetmer.nl/irc-logs/whatwg/20110930#l-81
An example in §4.8.11.1.11 Pixel Manipulation[1] states that the data
returned by getImageData() is at the resolution of the canvas backing
store, which is likely to not be one device pixel to each CSS pixel if
the display used is a
Tantek asked:
Could you provide a complete RDFa example of what you're attempting to
accomplish?
Stéphane replied:
p
This book has been authored by
span vocab=http://schema.org/; typeof=Person
a property=name rel=url href=http://smith.org/john;John
Smith/a
/span
/p
This
I wrote:
This could be represented in Microdata without an extra element:
p itemscope
This book has been authored by
span itemprop=name
a itemprop=url href=http://smith.org/john;John
Smith/a
/span
/p
Not the same. The span element in my example was used to assert a type
Hi,
When adding[1] the placeholder= attribute to input type=number, one
of our engineers asked me about the behavior of content attributes that
don't apply to certain input types.
Consider for example input type=range. The spec says[2] [t]he
following content attributes *must not be specified*
Perhaps what is needed is some kind of in-reply-to attribute:
article id=beerI like beer/article
article id=firstreply in-reply-to=beerMe too!/article
or even:
article id=beerI like beer
article id=firstreply in-reply-to=beerMe too!/article
/article
There's the idea to borrow the
2. The title of atom entries is constrained to contain text only,
That's not quite right. atom:title is an Atom Text Construct, which,
despite having the word 'text' in its name, can contain all sorts of
things. atom:title is the same as atom:summary, atom:content,
and atom:rights, so the algo
Is there any value in adding an href or uri or similar attribute
to the cite element to indicate a location for a work (or
information about the work) or, in the case of a URI, an indicator
that can be used as a reference programmatically?
cite uri has a much worse fallback story than simply
From #attr-time-pubdate:
If specified, [pubdate=] indicates that the date and time given by
the element is the publication date and time of the nearest ancestor
article element. If the element has no ancestor article element, the
pubdate attribute must not be specified.
I think this
-whatwg.org/2009-May/019857.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020284.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020877.html
--
Edward O'Connor
Seems to be a listing element in 11.2.2 Display types
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#the-css-user-agent-style-sheet-and-presentational-hints
What's that?
It's an historical element that you shouldn't use.
See
Both FOAF and vCard have unstructured personal name properties
(foaf:name and v:fn) that address this.
But vCard required both N and FN, so if you only have FN, you can't get an N
without a lot of dictionary-based domain knowledge and special rules. (Or
you can make a GIGO N...)
Hmm ...
The HTML 5 spec doesn't give clear guidance on the choice between
strong and em tags.
The spec distinguishes between importance (strong) and emphasis
(em) like so:
The placement of emphasis changes the meaning of the sentence. The
element thus forms an integral part of the content.
and
diff -u shows a lot of difference, but most are cosmetic. (I gather
they're there because Hixie disagrees with some W3C pubrules but can't
get them changed.) Is there any page that lists the substantive
differences? Presumably the generation of the drafts is automated; is
the source file for
For instance it would be reasonable to use two images -- a filled star
and an unfilled star -- to represent a rating of something:
pRating: img src=1img src=1img src=1img src=0img src=0/p
You'd want the text version to be:
Rating: 3/5
HTML5 provides the meter element for this use
Hi.
Currently, the only elements which work with dfn automatic
cross-referencing are span, abbr, code, var, samp, and i.[1]
I'd like to suggest adding strong to that list.
My specific use-case is the use of RFC 2119 terms in HTML. My
boilerplate looks like this:
p
The key words dfnMUST/dfn,
that figure uses legend and not caption.
Ted
--
Edward O'Connor
[EMAIL PROTECTED]
Ense petit placidam sub libertate quietem.
. It would
just use the same label more than once.
I think Robert was referring to the click behavior of labels -- they
focus their corresponding form control. How would UAs choose between
multiple controls, if one label element pointed at them all?
Ted
--
Edward O'Connor
[EMAIL PROTECTED]
Ense petit
(having shed both
my naivite and my stubbornness).
Please excuse the analogy, but try thinking about it this way: canvas is
to Photoshop as SVG is to Illustrator.
Ted
--
Edward O'Connor
[EMAIL PROTECTED]
Ense petit placidam sub libertate quietem.
to spend 5 minutes each time trying to track down
that URL!
If you read the list via gmane (nntp), each post has an 'Archived-At'
header which points at the post on the web.
Ted
--
Edward O'Connor
[EMAIL PROTECTED]
Ense petit placidam sub libertate quietem.
presamp and
precode.
This seems like a potentially very natural way to convert RFC2629bis'
figure artwork elements into HTML5.
Ted
--
Edward O'Connor
[EMAIL PROTECTED]
Ense petit placidam sub libertate quietem.
53 matches
Mail list logo