(Apologies if the threading on this gets messed up. I was not subscribed to
the list when the original message was sent.)
I want to paint Eric's scenario more strongly, because it seems like people
think if it would rarely blow up then it doesn't matter.
If you want to handle _any_ request sent
On Sat, Apr 5, 2008 at 2:19 PM, Jeff Walden
[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
Peter Kasting wrote:
It doesn't matter if the stack will not _commonly_ be too deep, or if it
isn't too deep for the callers that you know about right now -- it might be
too deep at some point (after
On Sun, Apr 6, 2008 at 1:52 AM, Aaron Boodman [EMAIL PROTECTED] wrote:
We have on one hand authors with reasons
(however edge casey you may believe them to be) they would prefer the
API be asynchronous,
Here's another problem an async API would automatically address:
On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
- Processing a reply synchronously is awkward in any case, since you need
a callback.
I'm not sure I follow this argument, I actually come to the opposite
conclusion.
Say that a page is communicating with multiple
On Wed, Apr 16, 2008 at 6:41 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Peter Kasting wrote:
I think the argument assumed you were communicating with a single frame in
the common case, in which case the current API is more awkward than one in
which the postMessage() call itself returns
On Wed, Apr 30, 2008 at 10:58 AM, David Bolter [EMAIL PROTECTED]
wrote:
Specifically I would ask that:
1. scrollIntoView not do anything in the case that the element is already
fully visible (possibly in the middle of the viewport), or
2. ensureElementIsVisible to be added as described by
On Tue, May 6, 2008 at 6:44 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 14 Apr 2007, Geoffrey Garen wrote:
1.4
when not qualified to explicitly refer
when not qualified explicitly to refer
(split infinitive)
I prefer the current text.
How about when not qualified to refer
On Tue, Jul 29, 2008 at 5:10 PM, Russell Leggett
[EMAIL PROTECTED]wrote:
That is a performance killer.
I don't think it is as much of a performance killer as you say it is.
Correct me if I'm wrong, but the standard connection limit is two.
The standard connection limit is 6, not 2, as of
On Thu, Jul 31, 2008 at 2:31 AM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 30 Apr 2008, Peter Kasting wrote:
- Otherwise, if the element is not larger than the viewport, scroll
such
that the element is centered* in the viewport (within the scrolling
limits
-- if the element
On Wed, Oct 15, 2008 at 12:04 PM, Sander van Zoest [EMAIL PROTECTED]wrote:
I do not see why we are condoning hacks on top of hacks, when it is so
simple
to just specify hSpace and vSpace.
The entire problem is that it is not simple. It is less simple to spec,
less simple to declare, less
On Mon, Nov 17, 2008 at 1:58 PM, Pierre-Olivier Latour [EMAIL PROTECTED]wrote:
1) I don't remember any major media system I've dealt with so far having an
explicit pixel aspect ratio override API,
2) on the web, neither QT plug-in nor Flash have it,
3) in the case of this spec, the way it's
spec solution.
On Mon, 17 Nov 2008, Peter Kasting wrote:
The potential for problems seems
greater than the upside from authors correctly using this to do
emergency-overrides of particular videos whose sources they don't
control.
I don't understand why this attribute would cause problems
On Tue, Dec 30, 2008 at 3:38 AM, Ian Hickson i...@hixie.ch wrote:
The same engineers have since implemented this feature in Chrome also,
Incorrect. One engineer implemented a crude hack in a small portion of the
Chromium glue code that implements a fraction of the spec -- enough to make
Gmail
On Mon, Jan 19, 2009 at 4:53 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
Actually I was just poking around and noticed that we don't actually
support variation of spellcheck values within different parts of an editable
element. So I won't make any claims about how hard that is to support.
2009/1/20 Mikko Rantalainen mikko.rantalai...@peda.net
I agree. I think that specifying the spellcheck attribute would be a
mistake. It allows only forcing the automatic spell checking on or off
but it doesn't help a bit to allow mixing different languages on a
single page.
I don't see how
On Wed, Jan 21, 2009 at 1:15 AM, Mikko Rantalainen
mikko.rantalai...@peda.net wrote:
If the browser does not know the language of the content, how on earth
is it supposed to *correctly* spellcheck it?
As others have noted, the user's preferences are generally a better
indicator of how
On Wed, Jan 21, 2009 at 7:38 PM, Calogero Alex Baldacchino
alex.baldacch...@email.it wrote:
Why not to let the user choose the language, as it happens in word
processors? A UA can't choose accurately whether, for instance, color is a
correct American English, a wrong British English, or even
On Sun, Jan 25, 2009 at 10:52 AM, Křištof Želechovski kri...@wp.pl wrote:
Gmail can use
1. the localisation preferences chosen by the user in GMail configuration,
2. the localisation preferences chosen by the user in the browser
configuration
to determine the what language the user is likely
2009/1/26 Křištof Želechovski k...@mimuw.edu.pl
Q: Should the localization influence the spell checking mechanism?
A: Definitely, since the user is likely to write most messages in his
preferred UI language.
Which is why this is a perfectly valid input for the heuristic the UA uses
to
2009/1/27 Křištof Želechovski k...@mimuw.edu.pl
The original use of the spellcheck attribute was to switch spell checking
off
No, the _original_ use was to turn it on on fields where it would otherwise
have been on.
(I think we both believe it should generally be on). Using a private
On Wed, Jan 28, 2009 at 2:35 AM, Křištof Želechovski k...@mimuw.edu.plwrote:
*No, the _original_ use was to turn it on on fields where it would
otherwise have been on.
*
I do not understand. If spell checking would be on, why turn it on
explicitly?
I mistyped. The last word should
On Wed, Jan 28, 2009 at 10:27 AM, Křištof Želechovski k...@mimuw.edu.plwrote:
Spelling quizzes are an artificial example; they are not interesting once
spell checking is commonly available because the user can cheat by
temporarily using another control that is being checked.
They can cheat
On Tue, Mar 31, 2009 at 10:22 AM, Boris Zbarsky bzbar...@mit.edu wrote:
I agree that entering a week is pretty rare, though. ;)
As someone working on supporting new input types in WebKit: Supporting any
one form of date is nontrivial, but supporting the rest after you support
the first _is_
On Tue, Mar 31, 2009 at 12:58 PM, Maciej Stachowiak m...@apple.com wrote:
It depends on the quality of implementation you want to deliver. With a
nice visual date picker, the UI for picking a month or a week is probably
quite different from the UI for picking a day, which in turn would be
On Sat, Apr 4, 2009 at 12:56 PM, timeless timel...@gmail.com wrote:
sounds like a security nightmare.
Can you be less vague? We've had a number of security people vet this
already, so specific complaints would be very helpful.
PK
On Thu, May 7, 2009 at 5:51 PM, David Gerard dger...@gmail.com wrote:
The Thusnelda coder is outdoing H.,264 in current tests:
Be careful how glowing you make this sound -- this is on a particular
objective test (not subjective, and thus perversely less accurate in
reflecting how good do
On Fri, Jun 5, 2009 at 5:24 PM, King InuYasha ngomp...@gmail.com wrote:
The HTML 5 specification should definitely support a codec that fulfills
the following legal criteria:
At the end of the day, the spec does not mandate vendor behavior; rather
vendor consensus informs the spec. For
On Sun, Jun 7, 2009 at 6:41 PM, Robert Sayre say...@gmail.com wrote:
I
wrote about the practice of shipping encumbered software and calling
it open.
Where is the language where Google is calling H.264 open?
The closest I know of is Google Chrome is made possible by the Chromium
open source
On Sun, Jun 7, 2009 at 7:43 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
I don't think the particular parallel you've drawn there is the appropriate
one.
And I think you failed to answer the line in my email that asked what the
point of this tangent is.
PK
On Sun, Jun 7, 2009 at 8:13 PM, King InuYasha ngomp...@gmail.com wrote:
Google, Apple, and the other naysayers for Ogg video
I think you are officially Wasting Our Time when you say something like
Google... and the other naysayers about a company that is _shipping Ogg
audio and video support
sam.ku...@uclmail.net wrote:
2009/6/30 Peter Kasting pkast...@google.com
On Jun 30, 2009 2:17 AM, Sam Kuper sam.ku...@uclmail.net wrote:
2009/6/30 Silvia Pfeiffe...
As a contributor to multiple browsers, I think it's important to note the
distinctions between cases like Acid3 (where IIRC all
On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting pkast...@google.com
wrote:
There is no other reason to put a codec in the spec -- the primary reason
to spec a behavior (to document vendor consensus) does not apply
I don't believe Chris was speaking in any official capacity for YT or Google
any more than I am. I think it is inappropriate to conflate his opinion of
the matter with Google's. I have not seen _any_ official statement from
Google regarding codec quality.
As an aside, I think taking the
On Mon, Jul 13, 2009 at 1:43 AM, Philip Jägenstedt phil...@opera.comwrote:
Also, I've reported bugs on Safari and Chrome (I think, neither give
confirmation that the report has been sent successfully!)
That's odd. Both bugs.webkit.org and crbug.com tell me when I've filed a
bug, and give me
On Tue, Jul 14, 2009 at 3:39 AM, Honza Bambas hon...@allpeers.com wrote:
Target '_search' makes a link open in a sidebar (Opera) or sidebar-like
window (IE). For some offline web apps would be cool to open sidebar by just
one click. In other browsers (Firefox) web content could be open in a
On Tue, Jul 14, 2009 at 11:14 AM, Mike Shaver mike.sha...@gmail.com wrote:
which led me to believe that YouTube's opinion was part of the
relevant-vendor positions which led to the choice to not specify a
codec. If it's not relevant, then its inclusion was certainly quite
confusing
I am
Two unrelated comments.
First, it seems a bit odd to me that input type=email and input type=url
are validated (for typeMismatch problems) but input type=tel isn't. I
know it's prohibitively difficult to perfectly validate telephone number
formats given the variety around the world, but it's also
On Mon, Jul 20, 2009 at 12:56 PM, Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net wrote:
What's with alphanumeric notation ? I think of 555-WHATWG as a possibly
valid telephone number. It might be good to have an RFC on that. Or
maybe ITU has publicly available documents on
On Thu, Jul 23, 2009 at 2:48 PM, Manu Sporny mspo...@digitalbazaar.comwrote:
contribute ideas: great!
scrutinize them: wonderful!
form consensus: fail (but that's what the W3C is for, right?)
produce: fail (unless we don't want to scale the community)
Ian is really the only one that is
On Sun, Jul 26, 2009 at 7:16 PM, Manu Sporny mspo...@digitalbazaar.comwrote:
I'm not proposing that we allow people to directly stomp all over Ian's
specification - that wouldn't help anything. I am also not suggesting
that Ian should change how he authors his HTML5 specification.
What I'm
On Mon, Jul 27, 2009 at 12:06 PM, John Foliot jfol...@stanford.edu wrote:
That said, the barrier to equal entry remains high:
http://burningbird.net/node/28
I don't understand. That page says We're told that to propose changes to
the document for consideration, we need to ... and then a long
On Tue, Jul 28, 2009 at 9:24 PM, Michael Davidson m...@google.com wrote:
These are true, but leave out the part that rewriting large apps to
the worker API is nontrivial. A major advantage of a hidden page (as
you mention below) is that the programming model is well known, and
easy for web
On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson m...@google.com wrote:
Personally, I'd rather have my CPU and RAM used to send spam than to
have pictures of me in my underwear publicly placed on Facebook.
The rest of the world would rather not receive that spam, and would probably
rather we
On Tue, Jul 28, 2009 at 9:47 PM, Michael Davidson m...@google.com wrote:
I agree 100%. I'm only trying to argue that from a user perspective,
access that we currently have acceptable UI for, e.g. camera hardware,
is about as scary as agreeing to let a web app run in the background.
The whole
On Fri, Aug 14, 2009 at 12:35 PM, João Eiras jo...@opera.com wrote:
From an implementor's point of view it is much harder to implement and keep
up with a mutating specification. During implementation a stable spec is
preferred.
As a browser implementer, I have certainly not found the dynamic
On Mon, Aug 24, 2009 at 9:08 AM, Chris Taylor chris.tay...@figureout.comwrote:
It's been mentioned before about limiting the length of text permissible in
a textarea element, specifically for forums.
textarea is defined to support maxlength already (
On Mon, Aug 24, 2009 at 5:19 PM, TAMURA, Kent tk...@chromium.org wrote:
http://www.whatwg.org/specs/web-apps/current-work/#e-mail-state
A valid e-mail address is a string that matches the production
dot-atom-text @ dot-atom-text
where dot-atom-text is defined in RFC 5322 section 3.2.3.
On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren ann...@opera.comwrote:
Also, maxlength cannot be enforced as client-side validation requirement
due to compatibility issues.
I don't grasp what you're saying here. Are you saying that maxlength or
ValidityState.tooLong() cannot be
On Tue, Aug 25, 2009 at 12:50 AM, Alex Vincent ajvinc...@gmail.com wrote:
The validationMessage attribute must return the empty string if the
element is not a candidate for constraint validation or if it is one
but it satisfies its constraints; otherwise, it must return a suitably
localized
On Tue, Aug 25, 2009 at 7:56 PM, Dean Edwards dean.edwa...@gmail.comwrote:
Looking through the spec I see the following DOM properties:
* formNoValidate
* novalidate
* willValidate
novalidate sticks out like a sore thumb. Can we change it to
noValidate. It's only mentioned in the IDL so
On Wed, Aug 26, 2009 at 4:01 PM, Linus Upson li...@google.com wrote:
The analogy was made comparing a user agent that purges local storage to an
OS throwing out files without explicit user action. This is misleading since
most files arrive on your computer's disk via explicit user action. You
On Wed, Aug 26, 2009 at 4:31 PM, Michael Nordman micha...@google.comwrote:
A mandate from on high that says 'shall store forever and ever' will be
promptly ignored because its impossible to make that guarantee.
That's not the proposed mandate. The proposed mandate is thou shalt not
discard
On Wed, Aug 26, 2009 at 5:08 PM, Remco remc...@gmail.com wrote:
As far as I know, cookies work the same way as the proposed local
storage policy: once a cookie is created, the browser won't delete it
when space becomes a problem. The site controls the expiration date of
the cookie, and it can
On Wed, Aug 26, 2009 at 4:55 PM, Michael Nordman micha...@google.comwrote:
What seems inevitable are vista-like prompts to allow something (or prods
to delete something) seemingly unrelated to a user's interaction with a
site... please, oh please, lets avoid making that part of the web
On Wed, Aug 26, 2009 at 5:42 PM, Michael Nordman micha...@google.comwrote:
In addition to the key/value pair storage apis, i think we'd need to make
this distinction for databases and appcaches too. This distinction may be
better handled in a way not tied to a particular flavor on storage. Or
On Mon, Aug 31, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.org wrote:
Yes, this is pretty disconcerting since there's been OVERWHELMING support
for LocalStorage being treated as user-critical on this thread.
The spec says basically what you want except that it uses should. It
seems like
On Mon, Aug 31, 2009 at 11:50 AM, Jens Alfke s...@google.com wrote:
On Aug 31, 2009, at 11:35 AM, Peter Kasting wrote:
Again, the spec now says in 4.3: User agents should expire data from the
local storage areas only for security reasons or when requested to do so by
the user. The only
On Wed, Sep 2, 2009 at 11:08 AM, Jens Alfke s...@google.com wrote:
On Aug 31, 2009, at 12:04 PM, Peter Kasting wrote:
If you combine that statement with section 6.1's User agents should
present the persistent storage feature to the user in a way that does not
distinguish them from HTTP
On Thu, Sep 3, 2009 at 6:49 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
You could just *not* specify that LocalStorage is worthless for
anything but a cache.
This seems like a severe overstatement given the current spec. It's not
worthless. It won't be guaranteed to be thrown away all
On Thu, Sep 3, 2009 at 3:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
And more-than-a-cache-Storage can be explicitly turned off or have its
quota dropped to zero. If that's important, the browsers will make it
easy. And more importantly, they'll make it *consistent* (within the
On Thu, Sep 3, 2009 at 3:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Again, this is precisely what we as UA authors can do now, with the
current
spec. I'm not sure what you're arguing. Our job is to make sure users
whose philosophy is like Ian's are as well-served as users whose
On Thu, Sep 3, 2009 at 4:08 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
10 hours ago, Hixie said:
The fact that local storage can be used for cookie resurrection means we
have to make sure that clearing one clears the other. Anything else would
be a huge privacy issue (just as Flash has
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which gives
more background. Does that satisfy your request?
I think that later section actually muddies the waters.
Something like this would be more clear: If
On Thu, Sep 3, 2009 at 5:17 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 3 Sep 2009, Peter Kasting wrote:
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote:
There's more wording in a later section on cookie resurrection which
gives
more background. Does that satisfy your
On Thu, Oct 29, 2009 at 3:03 PM, Ryan Cannon r...@ryancannon.com wrote:
In order to correctly report the error to the user, I would have to do a
second check of the value to figure out the problem. The only way to
determine that the error was caused by too few characters as opposed to
invalid
On Tue, Nov 10, 2009 at 12:23 PM, Michelangelo De Simone micde...@gmail.com
wrote:
What is the rationale about this choice? A simpler behavior with a
predetermined list of return values (eg: i.validationMessage ==
VALUEMISSING) could be much more efficient for authors and implementors to
2009/11/19 Scott González scott.gonza...@gmail.com
However, following that same logic wouldn't you come to the conclusion that
date inputs should not display calendars because they need to be localized?
* I am confused, what needs to be localized about the calendar? Are you
referring to
On Thu, Feb 11, 2010 at 6:39 PM, Ian Hickson i...@hixie.ch wrote:
The relevant use cases that led to this design are:
1. Getting validation of forms without scripting, with the UA doing all
the UI work.
2. Getting validation of forms with the UI designed by the author, but
with the
On Thu, Feb 11, 2010 at 11:01 PM, Jonas Sicking jo...@sicking.cc wrote:
Would be great if you could provide a reason why you feel this way.
Did the previous messages in the thread not say enough reasons? Ian's
response was basically then how would we solve use cases 1 and 2? which
was why I
On Wed, Feb 24, 2010 at 4:30 PM, Garrett Smith dhtmlkitc...@gmail.comwrote:
Where is the argument for making the API async?
Please see the discussion earlier in this thread.
Can you be more specific? I see:
| I really think the API should be asynchronous, as to avoid the mess
| that
On Thu, Jun 3, 2010 at 3:48 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent tk...@chromium.org wrote:
Oh, I'm sorry. I have found a sentence about visibility in the draft.
On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent tk...@chromium.org wrote:
There are some objections against omitting invisible controls from form
validation. However, it is a real issue with existing sites and users can't
submit such forms at all though they can submit it with non-HTML5
On Thu, Jul 1, 2010 at 11:38 AM, Christoph Päper
christoph.pae...@crissov.de wrote:
I have not found much on sortable tables on whatwg.org, especially when
excluding ‘datagrid’.
Why are you excluding datagrid, when that's the precise element aimed at
addressing your issue?
PK
On Sat, Jul 10, 2010 at 9:14 PM, Garrett Smith dhtmlkitc...@gmail.comwrote:
The few headings that you have are improperly capitalized.
I think you are mistakenly assuming that the authors of email and article
are the same person.
PK
On Fri, Jul 23, 2010 at 8:59 PM, Silvia Pfeiffer
silviapfeiff...@gmail.comwrote:
Is that URLs as values of attributes in HTML or is that URLs as pasted into
the address bar? I believe their processing differs...
I strongly suggest ignoring browser address bars. As the author of most of
the
On Wed, Oct 13, 2010 at 4:12 PM, a...@ashleysheridan.co.uk
a...@ashleysheridan.co.uk wrote:
Would it not be best to implement this based in the browser search
integration thing that allows people to include a search option to a site
through the browser, like YouTube, php.net, etc.
I can't
On Wed, Oct 13, 2010 at 6:53 PM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
On Wed, Oct 13, 2010 at 7:18 PM, Peter Kasting pkast...@google.com
wrote:
I can't for the life of me figure out what you're saying.
I assume he's saying that this should be integrated
On Thu, Oct 14, 2010 at 11:09 AM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
If this is meant to be vendor-neutral, there needs to be some way for
arbitrary search engines to advertise support for this feature to
supporting browsers.
That depends on whether the
On Mon, Feb 28, 2011 at 4:42 PM, Ian Hickson i...@hixie.ch wrote:
2. if we are still keeping them, can we disable them in
onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in
those events to confuse users, so that they can trap users for little
longer.
That's not a bad
On Tue, Mar 1, 2011 at 1:13 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote:
FWIW, chromium is planning on experimenting with disallowing modal dialogs
during the beforeunload/unload events.
On Wed, Apr 6, 2011 at 1:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Checkboxes being readonly would be useful for the same reasons that
text inputs being readonly is.
As someone who spends a lot of time writing native UIs, I agree. It's
useful to be able to dim out a checkbox that no
On Wed, Apr 6, 2011 at 4:37 PM, Andrew de Andrade
and...@deandrade.com.brwrote:
2) The HTML5 specification defines how browsers should implement this
consistently -- either a bar across the top OR modal dialog box, but
not both. This isn't ideal either since there are arguments both for
and
On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai o...@chromium.org wrote:
Do any browser vendors agree with this or have objections?
From my work on the Chrome UI side of this, I would very much like to see
something like isRegistered(). This would allow sites to conditionalize
requests for the
On Sun, Jul 3, 2011 at 12:11 AM, timeless timel...@gmail.com wrote:
It isn't ok to say You can't do X unless you make Y your default Z.
I would prefer to solve this if it actually becomes a problem. Right now
sites are actually much _more_ annoying without this feature as they just
blindly
In general, I echo Michael's comment that we follow the notifications model.
On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Right now sites are actually much _more_ annoying without this
feature as they just blindly ask you to make them your
On Tue, Jul 5, 2011 at 2:12 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Yes, I'm not saying in-page click is a solution. It works for popups, sort
of, but I don't think it does for permission request notifications.
To be truly honest, requiring a user gesture probably doesn't work for rPH()
On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik tan...@cs.stanford.eduwrote:
* existing rel=enclosure spec - download the link when clicked/activated.
I object to rel=enclosure purely on naming grounds. It is completely
unintuitive. I don't find the fact that a spec exists for it a compelling
On Fri, Jul 15, 2011 at 6:25 PM, Tantek Çelik tan...@cs.stanford.eduwrote:
** Specs *and* publishers/consumers/implementations of rel-enclosure exist
(see aforementioned wiki page).
The list on the wiki page, which I assume is non-exhaustive, is
extraordinarily uncompelling.
And the name
On Fri, Aug 26, 2011 at 2:08 PM, James Salsman jsals...@gmail.com wrote:
Maybe someone should ask the browser vendors how many img formats they
support and what the code footprint memory overhead would be for
adding rotation support for those which are likely to need it at
whatever confidence
On Tue, 17 May 2011, Bjartur Thorlacius wrote:
Then why add an API when we've already got (IMO superior) declarative
markup?
In the case of adding the API to the spec, because it's already
implemented. As to why it was added to the browsers, no idea.
Certainly there's no declarative
On Fri, Dec 16, 2011 at 3:08 PM, Peter Kasting pkast...@google.com wrote:
As for AddSearchProvider(), I know one reason it was added to Chrome was
explicitly to expose the and make default functionality.
I've been informed that the set default part is going away in Chrome 17+
anyway, so since
On Thu, Jan 26, 2012 at 12:15 AM, Ilya Sherman isher...@chromium.orgwrote:
Extending the existing input 'type' attribute is an interesting idea,
thanks for raising it. Looking through the existing input type values, it
seems they are primarily chosen so as to enable user agents to render and
On Sat, Mar 3, 2012 at 4:27 PM, Bjartur Thorlacius svartma...@gmail.comwrote:
In special,
a href=http://www.google.com/**url?sa=tamp;rct=jamp;q=l%C3%**
B6gbergamp;source=webamp;cd=**2amp;ved=0CCwQFjABamp;url=**
http%3A%2F%2Fwww.thingvellir.**is%2Fsaga%2Flogberg%2Famp;ei=**
On Mon, Jun 11, 2012 at 5:29 PM, Josh Aas josh...@gmail.com wrote:
In order for click-to-play to be a viable feature we'll probably need
to allow pages with complex plugin usage (i.e. scripting) to query for
click-to-play state.
The advice we (Chromium team) give developers is to check
On Tue, Jun 12, 2012 at 1:07 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Jun 12, 2012 at 1:22 PM, Peter Kasting pkast...@google.comwrote:
The temporary implementation
should probably be along the lines of reload the page, this time allowing
all plugins. As noted already in this thread
On Tue, Jun 12, 2012 at 1:26 PM, Ashley Sheridan
a...@ashleysheridan.co.ukwrote:
**
What about doing what popular plugin blockers do and offer the
notification in the area the plugin was intended to be used?
I was operating under the assumption the UA was already doing that. Hence
why we're
On Wed, Oct 31, 2012 at 4:08 PM, Ojan Vafai o...@chromium.org wrote:
On Wed, Oct 31, 2012 at 3:46 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I think what's happening here in Gecko is that a click on a focusable
element moves focus, and a click on an element's scrollbars counts as a
On Fri, Nov 2, 2012 at 6:21 AM, Etienne Levesque Guitard
etienn...@gmail.com wrote:
Wouldn't this be considered a browser-specific implementation
bug/inconsistency then?
If you're referring to IE's reported behavior, I would say that yes, it's
not gospel regarding platform conventions, and
On Wed, Nov 21, 2012 at 9:00 AM, Mounir Lamouri mou...@lamouri.fr wrote:
I feel like the real use case is when a user wants to make custom with a
web site for the first time. It might be indeed harder to get a good
transformation ration if the user has to write all those information.
However,
On Wed, Nov 21, 2012 at 5:11 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
The proper solution is to let people vote with their wallet for devices
that are perceived as making input easier – not to hand over power to
site users making it easier to sniff data.
This contains
1 - 100 of 112 matches
Mail list logo