On 01/11/2010 02:31, TAMURA, Kent wrote:
A team in Google tried to use input type=number for a product, and they
decided
not to use it.
What they needed was a control to select an integer from a specific integer
range
such as 1 - 16. The number type control in Opera and WebKit allow a user to
On 02/11/2010 11:46, Diego Perini wrote:
On Mon, Nov 1, 2010 at 3:31 AM, TAMURA, Kenttk...@chromium.org wrote:
A team in Google tried to useinput type=number for a product, and they
decided
not to use it.
What they needed was a control to select an integer from a specific integer
range
such
On 22 February 2010 01:18, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/21/10 7:11 PM, Dean Edwards wrote:
Why not just extend :empty to include input with no value?
Because that's not backwards-compatible and in fact violates the current CSS
spec?
It reads nicely:
input[required
On 22 February 2010 14:26, Tab Atkins Jr. jackalm...@gmail.com wrote:
It gets around the need for a new :placeholder pseudo-class:
input[placeholder]:empty {
color: red;
}
To get it to act like implementations do, you have to use
input[placeholder]:empty:not(:focus). That's pretty
On 22 February 2010 15:11, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/22/10 6:08 AM, Dean Edwards wrote:
There is a small chance that it could break some pages I guess.
So why is it worth it, then?
I was agreeing with you. That's why I suggested :no-value.
I always wanted a pseudo-class
On 21/02/2010 21:46, Aryeh Gregor wrote:
One implementation idea would be a pseudo-element, with something like
this in the UA stylesheet:
::placeholder { opacity: 0.6; }
Why not just extend :empty to include input with no value?
It reads nicely:
input[required]:empty:after {
content:
http://html5.validator.nu/?doc=http://www.whatwg.org/specs/web-apps/current-work/multipage/
-dean
On 08/12/2009 23:04, Garrett Smith wrote:
Setting an attribute to the empty string may have the effect of
removing the attribute in some browsers.
Which browsers/properties?
-dean
On 24/11/2009 15:24, Daniel Glazman wrote:
Anne van Kesteren wrote:
The problem is that it is a legacy feature, much like innerHTML.
That's not a problem. Make insertHTML with the new values and
make insertAdjacentHTML with the old values just an alias to
the new ones. Or the contrary. Or
On 17/11/2009 15:50, Bjartur Thorlacius wrote:
As the discussion had turned into bunch (good) advice giving, I
decided to repost this if anyone actually has opinion on this matter
and/or could tell me why the spec recommends firing hashchange on the
document instead of a specific element when a
On 14/10/2009 04:41, Ian Hickson wrote:
On Tue, 29 Sep 2009, Dean Edwards wrote:
It's going to take a while for IE7 to go away. In the meantime it
becomes an education issue -- You can start using HTML5 except
details which will look OK in some browsers but completely break
others
On 04/10/2009 15:51, Tab Atkins Jr. wrote:
dt only requires extra hacks in two browsers that are on the way
out. Given a little bit more time they'll be gone completely, and we
can stop worrying about this.
I'm sorry but you are really understating the problem here.
-dean
On 04/10/2009 18:11, Tab Atkins Jr. wrote:
On Sun, Oct 4, 2009 at 10:58 AM, Dean Edwardsdean.edwa...@gmail.com wrote:
On 04/10/2009 15:51, Tab Atkins Jr. wrote:
dtonly requires extra hacks in two browsers that are on the way
out. Given a little bit more time they'll be gone completely,
On 03/10/2009 03:38, Tab Atkins Jr. wrote:
Agreed, butdetails won't be usable at all in modern browsers
(without hacking support in via js) until everyone updates.
That's the whole point of this thread. We are specifying something that
won't be usable for years. Let's make the spec better so
On 02/10/2009 23:19, Michael Kozakewich wrote:
From: Anne van Kesteren ann...@opera.com
Sent: Tuesday, September 29, 2009 4:21 AM
The problem with allowing this is that
br/br
means
brbr
...
This does suck a little when introducing new void elements, but keeping
the syntax consistent is worth it
On 29/09/2009 20:08, Dean Edwards wrote:
You have two choices to get around the dd rendering bug:
1. The potentially dangerous document.write()
On 29/09/2009 18:10, Dean Edwards wrote:
There is a nasty side effect though. As you mentioned the
document.write() should be the last thing
On 02/10/2009 23:51, Tab Atkins Jr. wrote:
On Fri, Oct 2, 2009 at 5:35 PM, Dean Edwardsdean.edwa...@gmail.com wrote:
On 29/09/2009 21:55, Keryx Web wrote:
2009-09-29 21:53, Dean Edwards wrote:
Can't we just invent some new elements? We've already created 20
new ones. Two more won't hurt
This will also affect the figure element.
Test case:
http://dean.edwards.name/test/details.html
-dean
On 29/09/2009 16:12, Tab Atkins Jr. wrote:
On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwardsdean.edwa...@gmail.com wrote:
This will also affect thefigure element.
Test case:
http://dean.edwards.name/test/details.html
Luckily this has already been discovered and hacked around:
On 29/09/2009 17:55, Dean Edwards wrote:
On 29/09/2009 16:12, Tab Atkins Jr. wrote:
On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwardsdean.edwa...@gmail.com
wrote:
This will also affect thefigure element.
Test case:
http://dean.edwards.name/test/details.html
Luckily this has already been
On 29/09/2009 19:30, Keryx Web wrote:
2009-09-29 19:10, Dean Edwards skrev:
There is a nasty side effect though. As you mentioned the
document.write() should be the last thing in the head. If there are
any scripts following the document.write() then they are *not executed*.
I consider
On 29/09/2009 20:41, Tab Atkins Jr. wrote:
On Tue, Sep 29, 2009 at 2:08 PM, Dean Edwardsdean.edwa...@gmail.com wrote:
You have two choices to get around thedd rendering bug:
1. The potentially dangerous document.write()
2. Inserting weird conditional comments into your code:
/head
I'm currently writing a JavaScript implementation of the video element.
I'm running into problems with Opera9.52.
If I use the following markup then the text in the following p element
is coloured red:
video width=640 height=360 style=color:red
source src=bunny.ogv type=video/ogg
source
On 29/09/2009 03:21, Tab Atkins Jr. wrote:
On Mon, Sep 28, 2009 at 9:18 PM, Marius Gundersengunder...@gmail.com wrote:
Shouldn't you always close the tags, either self-closing or with a separate
close tag? That is, this is the correct way to do it:
video width=640 height=360 style=color:red
Hi all,
It's been a while. :)
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 maybe it's a typo.
-dean
Andrew Fedoniouk wrote:
I am not against new things really. It just appears as
UA will look like Christmas tree one day.
Each member of the family is adding their own stuff.
And someone put there SQL engine because it happens to lie on the shelf
nearby and granddad decide that his old canvas
Maciej Stachowiak wrote:
On May 19, 2007, at 4:27 PM, Dean Edwards wrote:
Maciej Stachowiak wrote:
On May 18, 2007, at 10:14 PM, liorean wrote:
On 19/05/07, Ian Hickson [EMAIL PROTECTED] wrote:
The uniqueID thing is really working around a deficiency in JS
(inability to use objects as keys
Maciej Stachowiak wrote:
On May 18, 2007, at 10:14 PM, liorean wrote:
On 19/05/07, Ian Hickson [EMAIL PROTECTED] wrote:
The uniqueID thing is really working around a deficiency in JS
(inability to use objects as keys). I think that's where it should be
addressed. The uniqueID idea has a number
Ian Hickson wrote:
A number of people made proposals related to sandboxing content to improve
Web security.
On Fri, 15 Dec 2006, Dean Edwards wrote:
When creating DHTML widgets (e.g. a colour picker) developers have to
battle the CSS cascade. A widget might be made of various HTML elements
Kristof Zelechovski wrote:
(as client side Lisp is my personal dream)
http://www.cs.stevens.edu/~dlong/software/kamen/index.php
-dean
Matthias Bauer wrote:
Is there any chance DOMContentLoaded will be part of HTML5?
Seems to have been forgotten:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-April/003709.html
-dean
Maciej Stachowiak wrote:
So to be sure I understand your proposal, you're suggesting that instead of
source type=audio/mpeg src=mysong.mp3
You'd say:
param type=audio/mpeg value=mysong.mp3
Why not call the element content instead of source? That way the src
and type attributes make more
Alexey Feldgendler wrote:
On Wed, 21 Feb 2007 11:28:47 +0100, Wolfram Kriesing [EMAIL PROTECTED]
wrote:
I was searching, but didnt find a hint-attribute for an input. The
more often we are using inline editing, the more the need for the
following is rising, imho:
From the semantic standpoint,
Elliotte Harold wrote:
I know that Web Forms 2.0 is specifically designed so that most of it
can be faked with JavaScript libraries as necessary. How far along is
that effort? I've found a few bits and pieces here and there via Google
such as https://sourceforge.net/projects/wf2/ but nothing
a native Windows implementation. We even mimic the user's
current XP theme. Download it and try it. I would appreciate any
feedback either privately or on this list.
https://sourceforge.net/projects/wf2/
-dean
Dean Edwards wrote:
Elliotte Harold wrote:
I know that Web Forms 2.0 is specifically
Anne van Kesteren wrote:
On Fri, 12 Jan 2007 17:34:03 +0100, James M Snell [EMAIL PROTECTED]
wrote:
Whatever shape the mechanism ultimately takes, having a way of isolating
scripts within a document would be extremely beneficial.
Thoughts?
Use an iframe and use cross-document messaging? This
When creating DHTML widgets (e.g. a colour picker) developers have to
battle the CSS cascade. A widget might be made of various HTML elements
which inherit style from the page. Sometimes inherited styles can mess
with the layout of your widget. So we end up coding stuff like this:
#widget div
Anne van Kesteren wrote:
On Fri, 15 Dec 2006 18:08:35 +0100, Dean Edwards [EMAIL PROTECTED] wrote:
Thoughts?
My thought is that this is a CSS issue and not a markup issue.
It feels right to fix it with markup. Maybe reset does not give the
right semantic meaning? But I hate the word
James Graham wrote:
But this element would be purely for the purpose of interacting with CSS
so it does indeed seem to be a CSS issue.
Not entirely. It also has some semantic value in that the element acts
as a container for other elements that comprise a widget. Perhaps
reset is the wrong
Alexey Feldgendler wrote:
Elements comprising a widget should carry appropriate semantic value by
themselves. For example, a properly styled unordered list can be used as
a color picker. widget should not be used as an excuse for writing a
bunch of meaningless divs to make a custom control.
Alexey Feldgendler wrote:
In this context, fieldset would express the meaning better.
I guess you're right.
I would still like a way to prevent CSS inheritance though. So far the
suggestions are:
1. reset element
2. inheritstyle=false attribute
3. cascade:off; CSS property
I don't really
Anne van Kesteren wrote:
Now I get your widget idea better. Perhaps it would be useful to
look into XBL?
Yes, XBL can already do this for me. But I get the feeling that I won't
be able to use it (cross-browser) until the year 2056. :-(
-dean
Douglas Crockford wrote:
I think the hazard is very real and very serious.
I don't see any additional expressiveness enabled by toJSONString.
No one is more concerned about the security of the platform than I am.
There isn't a security issue here. The hazard, if there is one, is
certainly
Ian Hickson wrote:
On Mon, 23 Oct 2006, Jonathan Worent wrote:
When asked if they would prefer a comma separated list or an array,
there were mixed feelings. Three indicated a preference to a comma
separated list, the other said he would expect to pass an array. Given
this I would suggest not
Ian Hickson wrote:
On Mon, 23 Oct 2006, Dean Edwards wrote:
Personally, I prefer a comma delimited list. Passing an array seems
yukky.
Really? I always thought the comma-separated argument to window.open() was
one of the ugliest APIs ever...
This isn't the same thing. We are faking
Anne van Kesteren wrote:
On Sun, 22 Oct 2006 20:03:48 +0200, Dean Edwards [EMAIL PROTECTED] wrote:
So what's the use case over matchAll(.foo.bar.baz) ..?
I didn't know that this had been implemented. Which browser is
supporting it?
It's not supported yet. What makes you think
Kornel Lesinski wrote:
On Mon, 02 Oct 2006 17:37:28 +0100, Shawn Wilsher [EMAIL PROTECTED]
wrote:
This project appears to be dead for over a year now. It seems to have at
least intention to support Gecko, but I couldn't get it to work properly
in Firefox.
Just because the project appears to
On 23/08/06, Francisco Monteiro [EMAIL PROTECTED] wrote:
How do you get workflow in a Web Application using only Web Browser
technology, Microsoft I think is the only company which will bring a
workflow to the masses, Using a combination of Dojo widgets we can achieve
something very similar see
Boris Zbarsky wrote:
Consider the following testcase:
!DOCTYPE html
a href=http://www.example.com; onclick=return 0Click me/a
Should clicking the link load www.example.com?
Yes. You should explicitly return false to cancel an event.
Most event handlers return nothing (undefined) which is
On 12/05/06, Andrew Fedoniouk [EMAIL PROTECTED] wrote:
This is in fact just one line:
var checked = root.select(input[type=checkbox]:checked);
You appear to be using a different DOM to everyone else.
-dean
On 11/05/06, Lachlan Hunt [EMAIL PROTECTED] wrote:
Dean Edwards wrote:
It would be great if NodeLists were subclasses of JavaScript Array
objects (especially with the introduction of Mozilla's Array Extras
[1]). This makes iteration over DOM queries more flexible.
It sounds like a nice idea
Some code to illustrate:
// old way
var isChecked = false;
var inputs = document.getElementsByTagName(input);
for (var i = 0; i inputs.length; i++) {
if (inputs[i].type == checkbox inputs[i].checked) {
isChecked = true;
break;
}
}
// better (using iterators on NodeList)
var isChecked =
On 11/05/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
My suggestion would be to have a renderingMode event (or something
like that) which in some way exposes a mediaList of the current
rendering modes (mostly just one). If you go to print preview mode for
example the event is dispatched and
On 10/05/06, Pablo Sánchez [EMAIL PROTECTED] wrote:
Hi,
I did some fixes on the IE Canvas made by Emil at http://eae.net/ and
the rotate method works fine. I even could get the Mozilla clock
sample to run.
But I can't get contact with Emil, his e-mail server keeps returning
my messages. Any
Jim Ley wrote:
On 10/05/06, Dean Edwards [EMAIL PROTECTED] wrote:
I suggested onbeforeprint/onafterprint events a while back. It got
shot down. :-(
How disappointing, let's hope the webapi wg look at it... there's
certainly existing implementations to just copy. They're useful
events
Michel Fortin wrote:
Le 3 avr. 2006 à 19:33, Dean Edwards a écrit :
Michel Fortin wrote:
Does that mean that a pattern attribute like foo|bar should
translate to /^foo|bar$/ ? Wouldn't it make more sense it it was
/^(foo|bar)$/ with the parentesis?
You have a point. Would implied
Michel Fortin wrote:
Something about the pattern attribute in Web Forms got me thinking:
The regular expression language used for this attribute is the same as
that defined in [ECMA262], except that the pattern attribute implies a
^ at the start of the pattern and a $ at the end (so the
Jim Ley wrote:
That is not immediately apparent, and neither is it apparent that a
classname specific shortname is worthwhile when a CSSSelector one
would be more appropriate.You don't continually add methods,
methods are complexity, they need writing, they need testing etc. you
have to
dolphinling wrote:
However, could it be made so the template attributes only apply to
fieldsets and wherever else they need to because of current parsing, as
opposed to all elements?
I believe this would mean it applied to fieldset, tr, and li (and
perhaps td, though that would be a strange
For the last few weeks four programmers (myself, Erik Arvidsson, Dimitri
Glazkov and Olav Junker Kjær) have been building an IE implementation of
Web Forms 2.0 for Internet Explorer.
We now have a working version available for testing. Because we are
programmers we are rubbish at testing
Ian Hickson wrote:
On Tue, 6 Sep 2005, Dean Edwards wrote:
That's right. We are defining HTML5 and the DOM extensions to support
it. If other languages want to add different class name delimiters, let
them. My hunch is that they will follow suit. This is a good opportunity
to make it clear
Ian Hickson wrote:
On Thu, 4 Aug 2005, Dean Edwards wrote:
Actually, the way the spec is written now, the UA _can_ assume that the
title attribute is going to help. In fact it is encouraged.
Assume that your proposal (hint) is spelt title and implement it like
that. (Including the little
fantasai wrote:
Dean Edwards wrote:
I know this has been suggested before, and was rejected, but I would
quite
like to see a pattern hint attribute added to Web Forms 2.0. With more
complex input controls we should spare a thought for the poor user.
http://www.whatwg.org/specs/web-forms
Dean Edwards wrote:
Matthew Raymond wrote:
Lachlan Hunt wrote:
Dean Edwards wrote:
fantasai wrote:
Dean Edwards wrote:
http://www.whatwg.org/specs/web-forms/current-work/#the-pattern
That is not enough. I wouldn't put something so complex in a
tooltip. It would frighten my users
I know this has been suggested before, and was rejected, but I would
quite like to see a pattern hint attribute added to Web Forms 2.0.
With more complex input controls we should spare a thought for the poor
user.
I've been trying to think of ways to feedback pattern mismatch help info
but
Matthew Raymond wrote:
| if (documentchanged) {
| printClone = document.clone();
| prepareForPrinting(printClone);
| }
|
| printClone.print();
This seems less practical than print events. It is also very difficult
to detect changes to the document. What do you mean by changes? Style
Ian Hickson wrote:
On Tue, 19 Jul 2005, Dean Edwards wrote:
The point is, I can do all sorts of things using script. Alter styles,
create elements etc. But when I switch media, I have no programmatic way
to alter those effects. Please specify I means to do this.
You don't switch media
Matthew Raymond wrote:
For instance, such events could be combined with AJAX to force people
into a pay-to-print scenario.
What's wrong with paying to print a high quality version of an image? If
you ask me this is a great example of why we should allow these events.
-dean
Olav Junker Kjær wrote:
Dean Edwards wrote:
IE has some nice onbeforeprint/onafterprint events. Can we add these too?
Arent these event mostly used to transform the view before printing it?
I think this is better handled by a print-specific style-sheet today.
If I set
Ian Hickson wrote:
On Mon, 18 Jul 2005, Dean Edwards wrote:
OK. Forget CSS for a moment (although this is still a consideration for
me). What if I want to suspend a timer while the page is being printed?
Printing is (supposedly) instantaneous. Why would you suspend a timer?
(And why would
Matthew Raymond wrote:
The common use of onbeforeprint/onafterprint is to add content to a
document that is only relevant to printed media, this is something
that cannot be done with CSS, since CSS is optional, so if we just
hide content with CSS, we're stuck with the situation that users
Mikko Rantalainen wrote:
- Clicking outside the calendar popup dismisses the popup and uses
the current values in the popup as the new date value.
This isn't good. How do I cancel? At least, put OK and Cancel
buttons in the popup.
Look at how a select works. Clicking outside the
Olav Junker Kjær wrote:
I agree that free-form input is quite nice, eg. if you have to enter
your own birth date, its much faster to type than to pick.
I really would like to see date widgets allow direct keyboard entry.
It's a very important feature for data entry systems.
-dean
Sjoerd Visscher wrote:
They are applied immediately (internally in some kind of buffer), but
not visible.
About when script is done, most cases are easy. But as always with
HTML there are hard edge cases.
Script from a script block is done when the last statement in that block
has been
Charles Iliya Krempeaux wrote:
To be honest, the think the idea of drawing transactions is better.
Here are the reasons:
#1: It makes it so, if the develop wants it, that they can have things
that are drawn show up immediately. (I.e., they aren't forced to
use double buffering [or whatever].)
Sjoerd Visscher wrote:
Charles Iliya Krempeaux wrote:
IMO, it would be better to a have solution to this built into the API.
Maybe with some kind of drawing transaction.
(A draw transaction is a little higher level than double
buffering, and allows you use other systems for this, other than
Hallvord R M Steen wrote:
Dear list,
often a page needs to interact with a plugin and tell it to load
another file. Today this is of course done with JavaScript, which is
difficult because most plugins have different JS interfaces, and there
are also differences between the plugins' ActiveX
Charles Iliya Krempeaux wrote:
From what I undestood (from what Sjoerd Visscher was saying), is that
there is no need for drawing transactions because of the way things
are done with JavaScript and the DOM.
Thanks for the very good explanation of drawing transaction. I wasn't
entirely
Ian Hickson wrote:
On Mon, 9 May 2005, Ben Meadowcroft wrote:
Discoverability would be left to the user agents.
Unless someone can come up with a way to make discoverability
practical and usable, there is no point us having this feature.
It is not all about user agents. I once had to build
Rob Mientjes wrote:
On 4/22/05, Jim Ley [EMAIL PROTECTED] wrote:
It has the semantics of a rendering context to which scripts can draw.
So it only has presentational semantics, so should be in a rendering
language like CSS?
That's the endless quandry. 'CSS can only do so much!' 'Markup should
be
Ian,
I'm not sure that Section 2 of WA1 belongs in the spec. None of it seems
to have much to do with web applications and it makes up 50% of the
document.
I know I've said this before but shouldn't this be a separate document?
Wasn't that the plan for the other bits and pieces of HTML5
There are some scripting tweaks I'd like to see in WA1. Apologies if
these have been covered already:
1) Mozilla's DOMContentLoaded event is very handy. It fires when a
node's content has been loaded and parsed (the DOM has been
constructed). This is much better than the standard onload event
Ian Hickson wrote:
On Wed, 20 Apr 2005, Dean Edwards wrote:
So you'd submit to a hidden iframe and then disable the main page?
Yep. The iframe then unlocks the page when submission is complete.
Forgetting about iframes for a minute. This is analogous to disabling
the entire application
Brad Fults wrote:
On 4/20/05, Dean Edwards [EMAIL PROTECTED] wrote:
Yes, but as I said initially, that creates a closure. This is not always
the most efficient solution. Your code won't work anyway because i is
variable. The closure would need to be more complicated to work properly.
Talking about
Brad Neuberg wrote:
* Right now most people directly access an elements className property,
without realizing that they might be clobbering multi-classed elements
(i.e. something with class=class1 class2). I usually have to create
wrapper methods to ensure that this doesn't happen, such as
dolphinling wrote:
+1
I would ask what semantics canvas has. ol means the content is an
ordered list, em means the content is emphasized, span and div mean the
content is different, but in a way not associated with any element. Even
img and object mean the content is external, (usually) with
Hey I like naming things! How about DEM for de-emphasise?
-dean
Henrik Lied wrote:
The element SMALL should be deprecated, as it describes the appearance
of the content.
Alternatively, a new name for the element could be created.
Since SMALL is usually used to describe copyright-notices and
Ian Hickson wrote:
On Thu, 24 Mar 2005, Csaba Gabor wrote:
2. Repetition model.
The Draft has a huge amount of space devoted to this,
but I haven't been able to think of a single compelling
argument for it. Most of the control enhancements such
as validation are conveniences, after all, but what
I've never known this group to be in such agreement! Jim? ;-)
-dean
James Graham wrote:
Olav Junker Kjær wrote:
Ian Hickson wrote:
Ok, would anyone object to us changing it to type=url? I don't feel
strongly about this.
Consistency with CSS is a very good point. URL is more widely known
and
Anne van Kesteren wrote:
output value=barfoo/output
Legacy UAs show foo where WF2 UAs show bar.
This is not consistent with textarea. I think they should behave the
same. output is effectively a read-only textarea.
-dean
Matthew Raymond wrote:
Dean Edwards wrote:
Matthew Raymond wrote:
I did a quick test, and using li in a dl produces a bullet on
Firefox, IE and Opera, whereas di and the complete lack of a parent
element did not. So, li didn't break anything, but it really didn't
have the desired rendering
91 matches
Mail list logo
