On Mon, Jul 13, 2015 at 8:09 AM, Elliott Sprehn wrote:
> Without such a function there's no primitive to explain how the scrolling
> and touch systems utilize this mayCancel bit unless we're saying the browser
> stores hidden state for event listeners in some WeakMap and all the browser
> systems
On Sun, Jul 12, 2015 at 11:52 PM, Elliott Sprehn wrote:
> This is what I had in mind as well. Also it occurs to me there's a missing
> primitive here for how the browser knows that all listeners have mayCancel:
> false so it can make this optimization. EventTarget needs some kind of
> method like:
On 7/12/15 12:47 PM, Ashley Gullen wrote:
1. Yes: statically references e.preventDefault
2. Maybe: some dynamic reference like e[str]
3: No: no dynamic references, and no static references to e.preventDefault
Assuming the "maybe" case is rare
Is there data supporting this assumption? I would
On Sat, Jul 11, 2015 at 11:40 PM, Anne van Kesteren
wrote:
> On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers wrote:
> > What Anne describes is perfect! I'm not hung up on the value of
> cancelable
> > itself - some internal bit on Event that makes preventDefault a no-op (or
> > event throw) during
body wants to write code in their JavaScript engine
> implementation that is aware of concepts like the DOM, events, methods
> specifically named "preventDefault," etc.
>
> -Original Message-
> From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of A
On Sun, Jul 12, 2015 at 7:49 PM, Jonas Sicking wrote:
> I think we've already made that assumption given that history.state
> already relies on this.
Good point. I'm still somewhat skeptical of introducing new objects
just for the purpose of grouping some properties if they don't serve a
purpose
On Sat, Jul 11, 2015 at 10:51 AM, Anne van Kesteren wrote:
> On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour wrote:
>> Minor bikeshed:
>> I have put scrollRestoration on history.options instead of directly history
>> itself in order to use history.options as an interface to contain any other
>>
On Fri, Jul 10, 2015 at 1:54 PM, Majid Valipour wrote:
> On Mon, Jun 29, 2015 at 5:20 PM Jonas Sicking wrote:
>>
>> FWIW I still prefer an API like
>>
>> history.scrollRestoration = 'manual';
>>
>> The main reason is that it seems to me that pushState/replaceState has
>> a largely orthogonal set
Generally nobody wants to write code in their JavaScript engine implementation
that is aware of concepts like the DOM, events, methods specifically named
"preventDefault," etc.
-Original Message-----
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Ashley G
Is it not possible for Javascript engines to statically determine if
preventDefault() is called by an event handler?
For example:
function myHandler(e)
{
// does "e.preventDefault" occur anywhere in this body?
};
target.addEventListener("scroll", myHandler);
If none of the added event handl
On Sat, Jul 11, 2015 at 11:41 PM, Rick Byers wrote:
> What Anne describes is perfect! I'm not hung up on the value of cancelable
> itself - some internal bit on Event that makes preventDefault a no-op (or
> event throw) during listener invocation is fine with me (and I agree - less
> weird). If
[On vacation now with only a phone - so apologies for the brevity and
top-posting]
What Anne describes is perfect! I'm not hung up on the value of cancelable
itself - some internal bit on Event that makes preventDefault a no-op (or
event throw) during listener invocation is fine with me (and I ag
On Sat, Jul 11, 2015 at 8:19 PM, Domenic Denicola wrote:
> I'm not sure that actually matters though, since canceling inside
> setTimeout(,0) shouldn't have much affect besides changing
> `e.defaultPrevented`. So maybe it's OK.
It's fine. The code that dispatches an event and then checks the
ev
From: Anne van Kesteren [mailto:ann...@annevk.nl]
>> 2) Should mayCancel=false listeners always get an Event with
>> cancelable=false, or is this "just a hint" such that all listeners
>> still get the same event with the same properties.
>> https://github.com/RByers/EventListenerOptions/issues/
On Fri, Jul 10, 2015 at 10:54 PM, Majid Valipour wrote:
> Minor bikeshed:
> I have put scrollRestoration on history.options instead of directly history
> itself in order to use history.options as an interface to contain any other
> restoration related attributes which have similar semantics (e.g.,
On Fri, Jul 10, 2015 at 9:12 PM, Rick Byers wrote:
> 1) Should we extend the existing addEventListener API or change the API
> names (and perhaps other things) completely.
> https://github.com/RByers/EventListenerOptions/issues/18
It seems most other "DOM peers" are okay with overloading the thir
f directly history
itself in order to use history.options as an interface to contain any other
restoration related attributes which have similar semantics (e.g., recorder
scroll position, scale restoration, recorded scale).
Majid
[1]
https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Apr/0123.html
Let me try to summarize the primary debate around this API so far. There
are (at least) two major questions which I think block creating a proper
pull request for suggesting concrete changes to the spec:
1) Should we extend the existing addEventListener API or change the API
names (and perhaps ot
On Thu, Jul 9, 2015 at 6:03 PM, Jonas Sicking wrote:
> On Thu, Jul 9, 2015 at 12:06 PM, Rick Byers wrote:
> > On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers wrote:
> >>
> >>
> >> On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking wrote:
> >>>
> >>> On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky
> wrot
On Thu, Jul 9, 2015 at 12:06 PM, Rick Byers wrote:
> On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers wrote:
>>
>>
>> On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking wrote:
>>>
>>> On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky wrote:
>>> > On 7/9/15 1:32 PM, Rick Byers wrote:
>>> >>
>>> >> Done. How
On Thu, Jul 9, 2015 at 2:59 PM, Elliott Sprehn wrote:
>
> On Thu, Jul 9, 2015 at 11:52 AM, Rick Byers wrote:
>
>> On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking wrote:
>>
>> ...
>>
>> I agree 100% with this principle. Changed mayCancel to default to false:
>>
>> https://github.com/RByers/EventL
On Thu, Jul 9, 2015 at 2:57 PM, Rick Byers wrote:
>
> On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking wrote:
>
>> On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky wrote:
>> > On 7/9/15 1:32 PM, Rick Byers wrote:
>> >>
>> >> Done. How does example 2 look now?
>> >>
>> >>
>> http://rbyers.github.io/
On Thu, Jul 9, 2015 at 11:52 AM, Rick Byers wrote:
> On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking wrote:
>
> ...
>
> I agree 100% with this principle. Changed mayCancel to default to false:
>
> https://github.com/RByers/EventListenerOptions/commit/b6ca043c9f13cea773a9338d580a0ebc24ea8140
> .
>
On Thu, Jul 9, 2015 at 2:24 PM, Jonas Sicking wrote:
> On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky wrote:
> > On 7/9/15 1:32 PM, Rick Byers wrote:
> >>
> >> Done. How does example 2 look now?
> >>
> >>
> http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
> >
> >
On Thu, Jul 9, 2015 at 2:21 PM, Jonas Sicking wrote:
> >> Speaking
> >> of that, having a new function makes it an option to let mayCancel be
> >> false by default, compat-wise at least.
> >
> > That's a good question regardless of which approach we take. Filed
> > https://github.com/RByers/Event
On Thu, Jul 9, 2015 at 11:05 AM, Boris Zbarsky wrote:
> On 7/9/15 1:32 PM, Rick Byers wrote:
>>
>> Done. How does example 2 look now?
>>
>> http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
>
> Looks like it would work. Also looks kind of ugly because of the
> obje
>> Speaking
>> of that, having a new function makes it an option to let mayCancel be
>> false by default, compat-wise at least.
>
> That's a good question regardless of which approach we take. Filed
> https://github.com/RByers/EventListenerOptions/issues/17
I definitely think that if we're going t
On 7/9/15 1:32 PM, Rick Byers wrote:
Done. How does example 2 look now?
http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html#example_2
Looks like it would work. Also looks kind of ugly because of the
object-truthiness bit, but I'm not sure there's any way to avoid that
whi
On Thu, Jul 9, 2015 at 12:47 PM, Rick Byers wrote:
> On Thu, Jul 9, 2015 at 12:40 PM, Boris Zbarsky wrote:
>
>> On 7/9/15 8:42 AM, Philip Jägenstedt wrote:
>>
>>> Would there be any way to feature detect support for
>>> EventListenerOptions as the third
>>> argument?
>>>
>>
>> Yes. You call add
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Rick Byers
> That seems like a nice incremental compromise. Using a new name for
> addEventListener will help address some of the feature detection /
> compatiblity concerns too. Filed
> https://githu
On Thu, Jul 9, 2015 at 12:40 PM, Boris Zbarsky wrote:
> On 7/9/15 8:42 AM, Philip Jägenstedt wrote:
>
>> Would there be any way to feature detect support for EventListenerOptions
>> as the third
>> argument?
>>
>
> Yes. You call addEventListener and pass an object that has getters for
> the prop
On Thu, Jul 9, 2015 at 6:40 PM, Boris Zbarsky wrote:
> On 7/9/15 8:42 AM, Philip Jägenstedt wrote:
>>
>> Would there be any way to feature detect support for EventListenerOptions
>> as the third
>> argument?
>
>
> Yes. You call addEventListener and pass an object that has getters for the
> proper
On 7/9/15 8:42 AM, Philip Jägenstedt wrote:
Would there be any way to feature detect support for EventListenerOptions as
the third
argument?
Yes. You call addEventListener and pass an object that has getters for
the properties you care about detecting. If those getters get invoked,
the bro
On Thu, Jul 9, 2015 at 11:40 AM, Philip Jägenstedt
wrote:
> On Thu, Jul 9, 2015 at 5:30 PM, Rick Byers wrote:
> > On Thu, Jul 9, 2015 at 11:22 AM, Anne van Kesteren
> wrote:
> >>
> >> On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers wrote:
> >> > I think there's a big opportunity to substantially im
On Thu, Jul 9, 2015 at 5:30 PM, Rick Byers wrote:
> On Thu, Jul 9, 2015 at 11:22 AM, Anne van Kesteren wrote:
>>
>> On Thu, Jul 9, 2015 at 5:15 PM, Rick Byers wrote:
>> > I think there's a big opportunity to substantially improve scroll
>> > performance on the web in the relatively short term by
be done.
> If we can get consensus on the basic approach, then I'd be happy to rework
> > my proposal in the form of a pull-request and move all issue tracking to
> > whatwg/dom. There's probably no point in doing that until we have an
> > agreement on the basic API shape, right?
>
> Fair.
>
>
> --
> https://annevankesteren.nl/
>
On Mon, Jul 6, 2015 at 2:47 AM, Mike West wrote:
> I've dropped the opener/openee-disowning behavior from my proposal,
> and renamed the sandboxing keyword to `allow-popups-to-escape-sandbox` in
>
> https://wiki.whatwg.org/index.php?title=Iframe_sandbox_improvments&diff=9958&oldid=9955
It appe
get consensus on the basic approach, then I'd be happy to rework
my proposal in the form of a pull-request and move all issue tracking to
whatwg/dom. There's probably no point in doing that until we have an
agreement on the basic API shape, right?
Fair.
h, then I'd be happy to rework
> my proposal in the form of a pull-request and move all issue tracking to
> whatwg/dom. There's probably no point in doing that until we have an
> agreement on the basic API shape, right?
Fair.
--
https://annevankesteren.nl/
o change drastically.
(I agree with Philip that if we add this it would need to become part
> of whatwg/dom. That seems like a better place for any GitHub
> discussion too.)
>
If we can get consensus on the basic approach, then I'd be happy to rework
my proposal in the form of a pull
need to become part
of whatwg/dom. That seems like a better place for any GitHub
discussion too.)
--
https://annevankesteren.nl/
On Thu, Jul 9, 2015 at 9:49 AM, Philip Jägenstedt wrote:
> On Thu, Jul 9, 2015 at 3:44 PM, Rick Byers wrote:
> > On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers wrote:
> >>
> >>
> >> On Thu, Jul 9, 2015 at 9:05 AM, James Ross <
> w3c-20040...@james-ross.co.uk>
> >> wrote:
> >>>
> >>> > Date: Thu, 9
On Thu, Jul 9, 2015 at 3:44 PM, Rick Byers wrote:
> On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers wrote:
>>
>>
>> On Thu, Jul 9, 2015 at 9:05 AM, James Ross
>> wrote:
>>>
>>> > Date: Thu, 9 Jul 2015 14:42:07 +0200
>>> > From: phil...@opera.com
>>> >
>>> > I think this looks like a very promising ap
On Thu, Jul 9, 2015 at 9:39 AM, Rick Byers wrote:
>
> On Thu, Jul 9, 2015 at 9:05 AM, James Ross
> wrote:
>
>> > Date: Thu, 9 Jul 2015 14:42:07 +0200
>> > From: phil...@opera.com
>> >
>> > I think this looks like a very promising approach. Would there be any
>> > way to feature detect support fo
On Thu, Jul 9, 2015 at 9:05 AM, James Ross
wrote:
> > Date: Thu, 9 Jul 2015 14:42:07 +0200
> > From: phil...@opera.com
> >
> > I think this looks like a very promising approach. Would there be any
> > way to feature detect support for EventListenerOptions as the third
> > argument? It seems like
> Date: Thu, 9 Jul 2015 14:42:07 +0200
> From: phil...@opera.com
>
> I think this looks like a very promising approach. Would there be any
> way to feature detect support for EventListenerOptions as the third
> argument? It seems like a problem that addEventListener(type,
> callback, { mayCancel
callback, true) in existing browsers.
Also, I think that this would make good sense as part of DOM itself,
in particular to get rid of the "calls to preventDefault will be
ignored" patching of DOM algorithms. https://github.com/whatwg/dom is
open for pull requests, or at least I've done some trivial ones.
Anne, what do you think?
Philip
On Wed, Jul 8, 2015 at 4:04 PM, Olli Pettay wrote:
> On 07/08/2015 10:12 PM, Rick Byers wrote:
>
>> [Cross-posted to www-...@w3.org - please let me know if there's a better
>> way to account for the DOM spec duality]
>>
>> In Chromium we've long worked hard at maximizing scroll performance, with
On 07/08/2015 10:12 PM, Rick Byers wrote:
[Cross-posted to www-...@w3.org - please let me know if there's a better
way to account for the DOM spec duality]
In Chromium we've long worked hard at maximizing scroll performance, with
scroll-blocking DOM events (wheel and touchstart in particular) b
On Wed, Jul 8, 2015 at 12:12 PM, Rick Byers wrote:
> [Cross-posted to www-...@w3.org - please let me know if there's a better
> way to account for the DOM spec duality]
>
> In Chromium we've long worked hard at maximizing scroll performance, with
> scroll-blocking DOM events (wheel and touchstart
[Cross-posted to www-...@w3.org - please let me know if there's a better
way to account for the DOM spec duality]
In Chromium we've long worked hard at maximizing scroll performance, with
scroll-blocking DOM events (wheel and touchstart in particular) being by
far the biggest source of scroll jan
On Tue, Jul 7, 2015 at 9:41 PM, Philip Jägenstedt wrote:
> Unsurprisingly, I like this, as it's basically what Presto did. However, I
> think preload="metadata" should reach HAVE_CURRENT_DATA, because you do
> want to decode the first frame. The naming mismatch is weird, but oh well.
>
OK.
> >
On Tue, Jul 7, 2015 at 4:48 AM, Robert O'Callahan
wrote:
> On Tue, Jul 7, 2015 at 1:44 AM, Philip Jägenstedt
> wrote:
>
>> On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan
>> wrote:
>>
>> > On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt
>> > wrote:
>> >
>> >> On Wed, Jun 10, 2015 at 6:53
On 2015/07/06 20:44, Philip Jägenstedt wrote:
It's unfortunate that load() means anything more than to run the media
element load algorithm, but it's not crazy that load() actually load
something, so I agree that we should spec this behavior somehow. Can
you file a spec bug at https://whatwg.org/
On Tue, Jul 7, 2015 at 1:44 AM, Philip Jägenstedt wrote:
> On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan
> wrote:
>
> > On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt
> > wrote:
> >
> >> On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan <
> rob...@ocallahan.org>
> >> wrote:
> >> > In G
On Wed, Jun 24, 2015 at 3:30 PM, Barry Smith wrote:
> ...
>>>
>>>
> When I build a website that is to have more than one page, and I want the
> "banner" to be the same across all pages, I use the element with
> a
> javascript file embedded inside, like this:
>
>
>
>
>
> and the javascript
On Mon, Jul 6, 2015 at 9:14 PM, Boris Zbarsky wrote:
> On 7/6/15 5:47 AM, Mike West wrote:
>
>> Boris, I think this is consistent with your suggestions in
>>
>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ
>> and
>>
>> https://groups.google.com/a/chromium.org/
On 7/6/15 5:47 AM, Mike West wrote:
Boris, I think this is consistent with your suggestions in
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/F6WGG03FafAJ
and
https://groups.google.com/a/chromium.org/d/msg/blink-dev/wXbgxLu63Fo/pZZ0MXzpbKAJ.
Can you live with this naming/beh
On Mon, Jul 6, 2015 at 2:19 PM, Robert O'Callahan
wrote:
> On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt
> wrote:
>
>> On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan
>> wrote:
>> > In Gecko, doesn't fire "canplay". This is
>> > allowed (encouraged, even) by the spec, since we can effi
On Mon, Jul 6, 2015 at 11:17 PM, Philip Jägenstedt
wrote:
> On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan
> wrote:
> > In Gecko, doesn't fire "canplay". This is
> > allowed (encouraged, even) by the spec, since we can efficiently satisfy
> > preload="metadata" by stopping decoding after on
On Wed, Jun 17, 2015 at 2:55 AM, Brian Birtles wrote:
> The HTMLMediaElement.load()[1] method currently cancels playback of the
> current resource and runs the resource selection algorithm[2] (and in turn
> the resource fetch algorithm[3]). When preload="none", however, the resource
> fetch algori
On Wed, Jun 10, 2015 at 6:53 AM, Robert O'Callahan wrote:
> In Gecko, doesn't fire "canplay". This is
> allowed (encouraged, even) by the spec, since we can efficiently satisfy
> preload="metadata" by stopping decoding after one frame, and if we only
> decode one frame then readyState will not ad
On Tue, Jun 23, 2015 at 11:14 AM, Mike West wrote:
> After some conversation with bz (CC'd), I've slightly formalized the
> description of the feature at
> https://wiki.whatwg.org/wiki/Iframe_sandbox_improvments.
>
> This is something that I'd like to ship in Chrome in the somewhat near
> future.
Pontus, you are right noticing the domain HAD or HAS nothing to do
necessarily, and the idea exposed before here in this thread was just
this, _an idea_. a WILL or a MIGHT.
Just keep in mind these _gTLD_ are new -- we would have not imagine
years ago, one will have to deal with specific domain
The domain does not necessarily correspond to or have any relation to the
website name. Furthermore, the domain is not necessarily readable language
- how does a screen reader know how to pronounce alistapart.com? It could
just as well read Ali's Tap Art.
You're right that it could have some secur
Hi all:
There was mentioned as a descendant element of the sectioning
element, just as an idea to solve the needs of the unacurate
use of the element it seems it occurs in our daily use, with
the current spec.
I could imagine other semantic elements,as long as e undertand the new
uses pop
I agree that the title/banner/logo element doesn't add much value. I don't
feel like a tag to canonically declare the website name would add much
value either - isn't that what the domain is for? Also the tag wouldn't be
very trustworthy - the domain is less easy to lie about.
On Wed, Jul 1, 2015
I don't see too much value in having a special element for the website
title/logo/branding as shown in-page.
I *can* see some value in canonically defining the website name inside
, e.g. for accessibility purposes. Let's say you navigate to a site
you're not familiar with via search results, a lin
On Wed, Jun 24, 2015 at 10:56 PM, Ryan Sleevi wrote:
>>[...] All
>>the forms except for decimal octets are seen as non-standard (despite
>>being quite widely interoperable) and undesirable.
They are no longer non-standard, though still non-conforming. Or, in
other words, https://url.
sounds nice to me.
As far as we move onto standarized browsers and mobile devices as the
way we connect to the web, the proposed could be equal to the
reference or representation shown in _svg=icon _or_ link-rel="ico"_
Just thinking.
---
Delfi Ramirez
My digital signature [1]
+34 633
On 30.06.15 03:18, Garrett Smith wrote:
On 6/29/15, Barry Smith wrote:
From: "Garrett Smith"
Hey Garrett,
My apologizes for not replying until now. When I posted my reply to the
"Site-Wide Heading Element" thread, you were right and I should have posted
a more complete example. Here is
I agree with Gary, perfect solution.
But, as I reach to understand, there is -- or there will be -- the need,
as devices and uses of web pages evolve, for thinking on or considering
some new descendant element tags of the ancestor .
May we extend the definition of the element beyond_ a grou
On 6/29/15, Barry Smith wrote:
> From: "Garrett Smith"
> Hey Garrett,
>
> My apologizes for not replying until now. When I posted my reply to the
> "Site-Wide Heading Element" thread, you were right and I should have posted
>
> a more complete example. Here is what I should have given as an e
FWIW I still prefer an API like
history.scrollRestoration = 'manual';
The main reason is that it seems to me that pushState/replaceState has
a largely orthogonal set of use cases that it tries to address from
scroll restoration. So I suspect that grouping the two together will
create awkwardness
On Mon, Jun 29, 2015 at 5:14 PM, Majid Valipour wrote:
> Do you have a preference one way or another for either of the above APIs?
Not really. The fact that history and navigation is not really
cross-browser makes me a bit wary about extending it further, since we
obviously don't really understan
On Wed, May 20, 2015 at 11:00 AM Majid Valipour
wrote:
>
> It will be great if we could make progress on getting a consensus on the
> API so that we can actually ship this feature. I think we have narrowed it
> down to two main options:
>
> 1- Setting scroll options using history.{push, replace}S
On Jun 26, 2015 14:30, "Edward O'Connor" wrote:
>
> Hi Tab,
>
> You wrote:
>
> >>> Sounds acceptable to me. What's the grammar of color=''? Just hex,
> >>> or full CSS ? (Either is fine with me.)
> >>
> >> We support full CSS colors. Though, we ignore the alpha component.
> >
> > Cool. When are we
Hi Tab,
You wrote:
>>> Sounds acceptable to me. What's the grammar of color=''? Just hex,
>>> or full CSS ? (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 p
On Fri, Jun 26, 2015 at 10:17 AM, Timothy Hatcher wrote:
> On Jun 24, 2015, at 2:39 PM, Tab Atkins Jr. wrote:
>> Sounds acceptable to me. What's the grammar of color=''? Just hex,
>> or full CSS ? (Either is fine with me.)
>
> We support full CSS colors. Though, we ignore the alpha component.
> On Jun 24, 2015, at 2:39 PM, Tab Atkins Jr. wrote:
>
> Sounds acceptable to me. What's the grammar of color=''? Just hex,
> or full CSS ? (Either is fine with me.)
We support full CSS colors. Though, we ignore the alpha component.
— Timothy Hatcher
We're considering supporting SVG in the places in the UI where we render the
icon in full color. Nothing to announce currently.
- Maciej
> On Jun 24, 2015, at 8:33 PM, Kevin Marks wrote:
>
> Does this mean we can now have rel=icon with SVG instead of providing a
> bitmap for every iOS device
On Thu, Jun 25, 2015 at 7:24 AM, Daniel Holbert wrote:
> From my brief testing with my testcase above (Chrome 45 dev channel on
> linux, Edge on Win10, Safari 8 on Yosemite), it doesn't look like other
> browser support SVG favicons right now, though.
FWIW, here’s the relevant Chromium issue:
htt
On 06/24/2015 08:33 PM, Kevin Marks wrote:
> Does this mean we can now have rel=icon with SVG instead of providing a
> bitmap for every iOS device specifically (when we add to homepage)? Do
> chrome and Firefox support SVG icon images?
Here's a simple testcase:
http://people.mozilla.org/~dholber
Does this mean we can now have rel=icon with SVG instead of providing a
bitmap for every iOS device specifically (when we add to homepage)? Do
chrome and Firefox support SVG icon images?
On 24 Jun 2015 2:40 pm, "Tab Atkins Jr." wrote:
> On Wed, Jun 24, 2015 at 2:36 PM, Maciej Stachowiak wrote:
On 6/24/15, Barry Smith wrote:
On Jun 23, 2015, at 22:57, Mark Simon wrote:
Hi Barry —
>
> When I build a website that is to have more than one page, and I want the
> "banner" to be the same across all pages, I use the element with
> a
> javascript file embedded inside, like this:
>
>
>
On Jun 23, 2015, at 22:57, Mark Simon wrote:
Presumably, the correct element is h1 for the banner heading, but this
may be at odds with the notion that h1 should describe the specific
page.
The banner title would be expected to be the same for most, if not all,
pages, while the h1 might be exp
On Wed, Jun 24, 2015 at 2:36 PM, Maciej Stachowiak wrote:
> To close the loop on this, we will change to href="whatever.svg" color="#aabbcc">. We like the idea of determining the
> color from the SVG, but we won't be able to implement in time for this cycle,
> and having an explicit color overr
To close the loop on this, we will change to . We like the idea of determining the color
from the SVG, but we won't be able to implement in time for this cycle, and
having an explicit color override seems useful. So for now we'll implement
explicit color and we'll consider automatic color picki
On 24/06/2015 9:08 pm, Jonathan Zuckerman wrote:
On Jun 23, 2015, at 22:57, Mark Simon wrote:
(This is my first post here, so I’m not sure about appropriate protocols).
HTML5 adds more power to the heading elements, which is a good thing. However,
there appears to be no recommended element
On Wed, Jun 24, 2015 at 1:50 PM, Tim Streater wrote:
> On 24 Jun 2015 at 20:15, Peter Kasting wrote:
>
> > 1.66 = 1.0.0.66
> > 1.256 = 1.0.1.0
> > 1.2.66 = 1.2.0.66
> > 1.256.66 = invalid
>
> This makes no sense at all.
>
https://tools.ietf.org/html/draft-main-ipaddr-text-rep-02#section-2.1.1
e
On 24 Jun 2015 at 20:15, Peter Kasting wrote:
> How Chrome's omnibox handles this (which I think is compliant with most
> other places):
>
> If there are no dots in the middle of the expression, the number is
> converted to powers-of-256 format and leading 0s are prepended to reach
> four octets
On Wed, Jun 24, 2015 at 9:37 AM, Tab Atkins Jr.
wrote:
> On Wed, Jun 24, 2015 at 9:23 AM, Anne van Kesteren
> wrote:
> > On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr.
> wrote:
> >> You swap between 0.0.0.66 and 66.0.0.0 in your OP.
> >
> > Actually, the input URL in that case is different. 0x
On Wed, Jun 24, 2015 at 9:23 AM, Anne van Kesteren wrote:
> On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. wrote:
>> You swap between 0.0.0.66 and 66.0.0.0 in your OP.
>
> Actually, the input URL in that case is different. 0x42.0. != 0x42.
Well *that's* confusing. ^_^ Def spec this in detail,
On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. wrote:
> You swap between 0.0.0.66 and 66.0.0.0 in your OP.
Actually, the input URL in that case is different. 0x42.0. != 0x42.
--
https://annevankesteren.nl/
On Wed, Jun 24, 2015 at 7:21 AM, Anne van Kesteren wrote:
> On Wed, Jun 24, 2015 at 3:46 AM, timeless wrote:
>> You have http://0.0.0.66/ that's not a match for your example...
>
> I'm not sure what you mean here.
You swap between 0.0.0.66 and 66.0.0.0 in your OP.
~TJ
On Wed, Jun 24, 2015 at 3:46 AM, timeless wrote:
> Also fun and probably worth documenting is how http://127.1/ and
> http://127.2.1/ are parsed. I doubt the average developer knows (unless they
> specifically deal with low level networking).
The question is whether the parsing happens at the URL
> On 24 Jun 2015, at 13:07, timeless wrote:
>
> Florian Rivoal wrote:
>> If a text input field has lang=foo, and your system has a (virtual)
> keyboard for language foo, I would expect that keyboard to be the one
> presented to you.
>
> The principle of least surprise argues against this.
>
>
http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/masinter/multipart-form-data/master/multipart-form-data.xml&modeAsFormat=html/ascii&type=ascii
> Encoding considerations:Common use is BINARY.
> In limited use (or transports that restrict the encoding to 7BIT
> On Jun 23, 2015, at 22:57, Mark Simon wrote:
>
> (This is my first post here, so I’m not sure about appropriate protocols).
>
> HTML5 adds more power to the heading elements, which is a good thing.
> However, there appears to be no recommended element for marking up a
> site-wide banner ti
Florian Rivoal wrote:
> If a text input field has lang=foo, and your system has a (virtual)
keyboard for language foo, I would expect that keyboard to be the one
presented to you.
The principle of least surprise argues against this.
Most mobile phones support many more languages and keyboard layo
701 - 800 of 40179 matches
Mail list logo
